Menu
▾
▴
kvm-devel
|
From: Andi K. <an...@fi...> - 2008-01-13 16:27:54
|
When I try my 64bit kernel with -kernel ... on kvm-59 I get before the kernel outputs anything: exception 13 (0) rax 0000000000000000 rbx 0000000000000000 rcx 0000000000000000 rdx 0000000000000600 rsi 0000000000000000 rdi 0000000000000000 rsp 0000000000000000 rbp 0000000000000000 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 0000000000010000 rflags 00033046 cs f000 (000f0000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr 0000 (08c00000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 0/ffff idt 0/ffff cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> fc f6 86 11 02 00 00 40 75 10 fa b8 18 00 00 00 8e d8 8e c0 8e e0 8e e8 8e d0 8d a6 e8 01 Aborted (core dumped) With kvm-49 user land it works just fine. Host is Intel-VT (Core2), kernel 2.6.24-rc5-git5 with the KVM modules out of the source tree. -Andi |
|
From: Avi K. <av...@qu...> - 2008-01-13 16:42:44
|
Andi Kleen wrote: > When I try my 64bit kernel with -kernel ... on kvm-59 I get before > the kernel outputs anything: > > Yes, I think -kernel is broken. Izik? -- error compiling committee.c: too many arguments to function |
|
From: Izik E. <iz...@qu...> - 2008-01-13 17:17:42
|
Avi Kivity wrote: > Andi Kleen wrote: >> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >> the kernel outputs anything: >> >> > > Yes, I think -kernel is broken. > > Izik? wasnt it was fixed with the qemu_ram_alloc(0xa0000) patch ??? (i remembred someone sent patch to fix it) i will check it tomorrow.... |
|
From: Anthony L. <an...@co...> - 2008-01-13 17:18:59
|
Izik Eidus wrote: > Avi Kivity wrote: > >> Andi Kleen wrote: >> >>> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >>> the kernel outputs anything: >>> >>> >>> >> Yes, I think -kernel is broken. >> >> Izik? >> > > wasnt it was fixed with the qemu_ram_alloc(0xa0000) patch ??? > (i remembred someone sent patch to fix it) > Yes, but that only fixes it for guests that don't cross the 4GB boundary. Regards, Anthony Liguori > i will check it tomorrow.... > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel > |
|
From: Andi K. <an...@fi...> - 2008-01-13 17:56:33
|
> If you are using a guest with more than 3.75GB or so. The load_kernel > function uses phys_ram_base + addr and that assumption is violated in > KVM with guests > ~3.75GB of memory. We either need to allocate memory > for the hole and never touch it or change load_kernel to use > cpu_physical_memory_rw. I know we discussed this before but I don't > remember if we came to a consensus about what the correct fix is? I used the default 128MB of RAM and the kernel also wasn't that big and also not linked to a high address (everything definitely < 16MB) -andi |
|
From: Andi K. <an...@fi...> - 2008-01-13 18:14:06
|
> Are you using the modules that come with kvm or from an upstream kernel? > (which?) kvm from 2.6.24-rc5-gitXXX upstream kernels (see my original mail) -Andi |
|
From: Andi K. <an...@fi...> - 2008-01-13 18:30:35
|
FWIW it seems things are broken even without -kernel in -59 too. If I try to boot an existing image with just -hda ... the VGA screen just stays black while the process runs at 99% CPU. Again with -49 it works fine. -Andi |
|
From: Andi K. <an...@fi...> - 2008-01-13 18:35:04
|
... and eventually it oopsed: Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<ffffffff8822c833>] :kvm:x86_emulate_memop+0x2c62/0x4527 PGD 11c8ae067 PUD 0 Oops: 0002 [1] SMP CPU 0 Modules linked in: xfrm_user xfrm4_tunnel af_key xfs kvm_intel kvm usblp deflate zlib_deflate zlib_inflate twofish_x86_64 twofish_common des_generic md5 sha1_ge neric tunnel4 ipcomp esp4 ah4 cifs sha256_generic serpent pppoe pppox ppp_generi c slhc autofs4 snd_pcm_oss snd_mixer_oss snd_seq ipt_MASQUERADE iptable_nat nf_n at_sip nf_conntrack_sip nf_nat_ftp nf_nat_irc nf_nat ip6t_LOG ip6t_REJECT ip6tab le_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack_ftp nf_co nntrack_irc cbc nf_conntrack blkcipher cpufreq_conservative ipt_LOG ipt_REJECT i ptable_filter ip_tables dm_crypt x_tables binfmt_misc aes_x86_64 eeprom lm85 hwm on_vid snd_usb_audio pl2303 snd_usb_lib usbserial snd_rawmidi appledisplay snd_h da_intel snd_seq_device snd_hwdep snd_pcm snd_timer snd snd_page_alloc i2c_i801 i2c_core Pid: 10723, comm: qemu-system-x86 Not tainted 2.6.24-rc5-git5-BASIL #1 RIP: 0010:[<ffffffff8822c833>] [<ffffffff8822c833>] :kvm:x86_emulate_memop+0x2c 62/0x4527 RSP: 0018:ffff81011d575738 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000044 RDX: 0000000000000000 RSI: ffff81011d5757d8 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000011b4b000 R09: 0000000000000001 R10: 00007fff581ec280 R11: ffffffff8823c388 R12: 0000000000000031 R13: 0000000000000000 R14: ffff81011d575908 R15: 0000000000000000 FS: 00002ac9553fd6e0(0000) GS:ffffffff80761000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010ef6e000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 Process qemu-system-x86 (pid: 10723, threadinfo ffff81011d574000, task ffff81009 e5d6000) Stack: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffffffff88237d20 0300000000000040 0000000000000000 030000000000004e 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Call Trace: [<ffffffff88224a7b>] :kvm:emulate_instruction+0xf6/0x21a [<ffffffff8823c809>] :kvm_intel:handle_exception+0x19f/0x210 [<ffffffff882250d4>] :kvm:kvm_vcpu_ioctl_run+0x29c/0x3ad [<ffffffff882252f2>] :kvm:kvm_vcpu_ioctl+0x10d/0xd7c [<ffffffff80291a09>] do_ioctl+0x21/0x6b [<ffffffff80291c96>] vfs_ioctl+0x243/0x25c [<ffffffff80291ceb>] sys_ioctl+0x3c/0x5d [<ffffffff8020be5e>] system_call+0x7e/0x83 [<00002ac9538b8b57>] Code: 66 89 10 eb 7b 8b 94 24 28 01 00 00 48 8b 84 24 38 01 00 00 RIP [<ffffffff8822c833>] :kvm:x86_emulate_memop+0x2c62/0x4527 RSP <ffff81011d575738> CR2: 0000000000000000 -Andi |
|
From: Alexey E. <al...@gm...> - 2008-01-13 18:41:53
|
Hi Andi, Please give us the _complete_ command line: how do you launch Qemu/KVM, and which Host and Guest OSes are? -- -Alexey Eremenko "Technologov" |
|
From: Andi K. <an...@fi...> - 2008-01-15 11:54:27
|
On Tue, Jan 15, 2008 at 12:56:52PM +0200, Avi Kivity wrote: > Andi Kleen wrote: > >FWIW it seems things are broken even without -kernel in -59 too. If I try > >to boot an existing image with just -hda ... the VGA screen just stays > >black while the process runs at 99% CPU. Again with -49 it works fine. > > > > > > Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git ought > to fix it. Thanks will try later. How about the oops in 2.6.24 I reported though? -Andi |
|
From: Avi K. <av...@qu...> - 2008-01-15 12:14:33
|
Andi Kleen wrote: > On Tue, Jan 15, 2008 at 12:56:52PM +0200, Avi Kivity wrote: > >> Andi Kleen wrote: >> >>> FWIW it seems things are broken even without -kernel in -59 too. If I try >>> to boot an existing image with just -hda ... the VGA screen just stays >>> black while the process runs at 99% CPU. Again with -49 it works fine. >>> >>> >>> >> Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git ought >> to fix it. >> > > Thanks will try later. How about the oops in 2.6.24 I reported though? > Will investigate, of course. Right now using my tglx timeslice to do -rt integration. -- error compiling committee.c: too many arguments to function |
|
From: Izik E. <iz...@qu...> - 2008-01-23 13:19:22
Attachments:
fix-decode.patch
|
Andi Kleen wrote: > On Tue, Jan 15, 2008 at 12:56:52PM +0200, Avi Kivity wrote: > >> Andi Kleen wrote: >> >>> FWIW it seems things are broken even without -kernel in -59 too. If I try >>> to boot an existing image with just -hda ... the VGA screen just stays >>> black while the process runs at 99% CPU. Again with -49 it works fine. >>> >>> >>> >> Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git ought >> to fix it. >> > > Thanks will try later. How about the oops in 2.6.24 I reported though? > > -Andi > > the bellow patch should fix this opss (it is targeted for 2.6.24-rc7) -- woof. |
|
From: Izik E. <iz...@qu...> - 2008-01-23 13:29:48
Attachments:
fix-decode2.patch
|
Izik Eidus wrote: > Andi Kleen wrote: >> On Tue, Jan 15, 2008 at 12:56:52PM +0200, Avi Kivity wrote: >> >>> Andi Kleen wrote: >>> >>>> FWIW it seems things are broken even without -kernel in -59 too. If >>>> I try >>>> to boot an existing image with just -hda ... the VGA screen just stays >>>> black while the process runs at 99% CPU. Again with -49 it works fine. >>>> >>>> >>>> >>> Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git >>> ought to fix it. >>> >> >> Thanks will try later. How about the oops in 2.6.24 I reported though? >> >> -Andi >> >> > the bellow patch should fix this opss > (it is targeted for 2.6.24-rc7) > sorry i forgat one break in this patch this is the fixed patch. -- woof. |
|
From: Avi K. <av...@qu...> - 2008-01-23 15:58:02
|
Izik Eidus wrote: >>> >> the bellow patch should fix this opss >> (it is targeted for 2.6.24-rc7) >> > sorry i forgat one break in this patch > this is the fixed patch. > Thanks, queued for 2.6.24. -- error compiling committee.c: too many arguments to function |
|
From: Anthony L. <an...@co...> - 2008-01-13 17:18:20
|
Avi Kivity wrote: > Andi Kleen wrote: > >> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >> the kernel outputs anything: >> >> >> > > Yes, I think -kernel is broken. > If you are using a guest with more than 3.75GB or so. The load_kernel function uses phys_ram_base + addr and that assumption is violated in KVM with guests > ~3.75GB of memory. We either need to allocate memory for the hole and never touch it or change load_kernel to use cpu_physical_memory_rw. I know we discussed this before but I don't remember if we came to a consensus about what the correct fix is? Regards, Anthony Liguori > Izik? > > |
|
From: Izik E. <iz...@qu...> - 2008-01-13 17:24:12
|
Anthony Liguori wrote: > Avi Kivity wrote: >> Andi Kleen wrote: >> >>> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >>> the kernel outputs anything: >>> >>> >> >> Yes, I think -kernel is broken. >> > > If you are using a guest with more than 3.75GB or so. The load_kernel > function uses phys_ram_base + addr and that assumption is violated in > KVM with guests > ~3.75GB of memory. We either need to allocate > memory for the hole and never touch it or change load_kernel to use > cpu_physical_memory_rw. I know we discussed this before but I don't > remember if we came to a consensus about what the correct fix is? > we can do munmap on the pci hole memory area, btw Anthony virtio will need this too right? > Regards, > > Anthony Liguori >> Izik? >> >> > |
|
From: Avi K. <av...@qu...> - 2008-01-13 18:08:56
|
Andi Kleen wrote: >> If you are using a guest with more than 3.75GB or so. The load_kernel >> function uses phys_ram_base + addr and that assumption is violated in >> KVM with guests > ~3.75GB of memory. We either need to allocate memory >> for the hole and never touch it or change load_kernel to use >> cpu_physical_memory_rw. I know we discussed this before but I don't >> remember if we came to a consensus about what the correct fix is? >> > > I used the default 128MB of RAM and the kernel also wasn't that big > and also not linked to a high address (everything definitely < 16MB) > > Just tried it and it works without a problem. Using kvm*.git though, not kvm-59. Are you using the modules that come with kvm or from an upstream kernel? (which?) -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-01-13 18:21:50
|
Andi Kleen wrote: >> Are you using the modules that come with kvm or from an upstream kernel? >> (which?) >> > > kvm from 2.6.24-rc5-gitXXX upstream kernels (see my original mail) > This points the finger at the memory allocation backward compatibility logic. Izik, can you take a look there? -- error compiling committee.c: too many arguments to function |
|
From: Izik E. <iz...@qu...> - 2008-01-13 18:25:05
|
Avi Kivity wrote: > Andi Kleen wrote: >>> Are you using the modules that come with kvm or from an upstream >>> kernel? (which?) >>> >> >> kvm from 2.6.24-rc5-gitXXX upstream kernels (see my original mail) > > This points the finger at the memory allocation backward compatibility > logic. > > Izik, can you take a look there? > > yes i will look on this tomorrow (as i said) (what weird about it that the new code is actualy protected by: kvm_qemu_check_extension(KVM_CAP_USER_MEMORY) call, so it shouldnt run i will see it tomorrow. |
|
From: Anthony L. <an...@co...> - 2008-01-13 20:24:28
|
Izik Eidus wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>> Andi Kleen wrote: >>> >>>> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >>>> the kernel outputs anything: >>>> >>>> >>> >>> Yes, I think -kernel is broken. >>> >> >> If you are using a guest with more than 3.75GB or so. The >> load_kernel function uses phys_ram_base + addr and that assumption is >> violated in KVM with guests > ~3.75GB of memory. We either need to >> allocate memory for the hole and never touch it or change load_kernel >> to use cpu_physical_memory_rw. I know we discussed this before but I >> don't remember if we came to a consensus about what the correct fix is? >> > we can do munmap on the pci hole memory area, > btw Anthony virtio will need this too right? Yup. I don't think you want to munmap memory allocated by glibc. I think a better thing to do would be to madvise(MADV_DONTNEED) although I don't think it's strictly needed. If you never touch the memory, then does it really matter? Regards, Anthony Liguori >> Regards, >> >> Anthony Liguori >>> Izik? >>> >>> >> > |
|
From: Izik E. <iz...@qu...> - 2008-01-13 21:51:34
|
Anthony Liguori wrote: > Izik Eidus wrote: >> Anthony Liguori wrote: >>> Avi Kivity wrote: >>>> Andi Kleen wrote: >>>> >>>>> When I try my 64bit kernel with -kernel ... on kvm-59 I get before >>>>> the kernel outputs anything: >>>>> >>>>> >>>> >>>> Yes, I think -kernel is broken. >>>> >>> >>> If you are using a guest with more than 3.75GB or so. The >>> load_kernel function uses phys_ram_base + addr and that assumption >>> is violated in KVM with guests > ~3.75GB of memory. We either need >>> to allocate memory for the hole and never touch it or change >>> load_kernel to use cpu_physical_memory_rw. I know we discussed this >>> before but I don't remember if we came to a consensus about what the >>> correct fix is? >>> >> we can do munmap on the pci hole memory area, >> btw Anthony virtio will need this too right? > > Yup. I don't think you want to munmap memory allocated by glibc. i was thinking about allocate the memory with mmap instead of the qemu qemu_malloc... > > I think a better thing to do would be to madvise(MADV_DONTNEED) > although I don't think it's strictly needed. If you never touch the > memory, then does it really matter? why to keep the virtual address size of a program 300mb larger than it really is? > > Regards, > > Anthony Liguori > >>> Regards, >>> >>> Anthony Liguori >>>> Izik? >>>> >>>> >>> >> > |
|
From: Avi K. <av...@qu...> - 2008-01-15 10:56:50
|
Andi Kleen wrote: > FWIW it seems things are broken even without -kernel in -59 too. If I try > to boot an existing image with just -hda ... the VGA screen just stays > black while the process runs at 99% CPU. Again with -49 it works fine. > > Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git ought to fix it. -- error compiling committee.c: too many arguments to function |
|
From: Laurent V. <Lau...@bu...> - 2008-01-23 13:43:34
|
Le mercredi 23 janvier 2008 =C3=A0 15:29 +0200, Izik Eidus a =C3=A9crit :
> Izik Eidus wrote:
> > Andi Kleen wrote:
> >> On Tue, Jan 15, 2008 at 12:56:52PM +0200, Avi Kivity wrote:
> >> =20
> >>> Andi Kleen wrote:
> >>> =20
> >>>> FWIW it seems things are broken even without -kernel in -59 too. If=20
> >>>> I try
> >>>> to boot an existing image with just -hda ... the VGA screen just sta=
ys
> >>>> black while the process runs at 99% CPU. Again with -49 it works fin=
e.
> >>>>
> >>>> =20
> >>>> =20
> >>> Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git=20
> >>> ought to fix it.
> >>> =20
> >>
> >> Thanks will try later. How about the oops in 2.6.24 I reported though?
> >>
> >> -Andi
> >>
> >> =20
> > the bellow patch should fix this opss
> > (it is targeted for 2.6.24-rc7)
> >
> sorry i forgat one break in this patch
> this is the fixed patch.
> if ((d & ModRM) && modrm_mod =3D=3D 3) {
> src.type =3D OP_REG;
[snip]
> break;
> }
> src.type =3D OP_MEM;
>=20
So src.type is OP_MEM and not OP_REG... is it what you want ?
Laurent
--=20
----------------- Lau...@bu... ------------------
"La perfection est atteinte non quand il ne reste rien =C3=A0
ajouter mais quand il ne reste rien =C3=A0 enlever." Saint Exup=C3=A9ry
|
|
From: Laurent V. <Lau...@bu...> - 2008-01-23 13:49:21
|
Le mercredi 23 janvier 2008 =C3=A0 14:38 +0100, Laurent Vivier a =C3=A9crit=
:
> Le mercredi 23 janvier 2008 =C3=A0 15:29 +0200, Izik Eidus a =C3=A9crit :
> > Izik Eidus wrote:
> > > Andi Kleen wrote:
> > >> On Tue, Jan 15, 2008 at 12:56:52PM +0200, Avi Kivity wrote:
> > >> =20
> > >>> Andi Kleen wrote:
> > >>> =20
> > >>>> FWIW it seems things are broken even without -kernel in -59 too. I=
f=20
> > >>>> I try
> > >>>> to boot an existing image with just -hda ... the VGA screen just s=
tays
> > >>>> black while the process runs at 99% CPU. Again with -49 it works f=
ine.
> > >>>>
> > >>>> =20
> > >>>> =20
> > >>> Yes, 6b8bb99a9cde386d72b4b7c22b92f4bdec333dab in kvm-userspace.git=20
> > >>> ought to fix it.
> > >>> =20
> > >>
> > >> Thanks will try later. How about the oops in 2.6.24 I reported thoug=
h?
> > >>
> > >> -Andi
> > >>
> > >> =20
> > > the bellow patch should fix this opss
> > > (it is targeted for 2.6.24-rc7)
> > >
> > sorry i forgat one break in this patch
> > this is the fixed patch.
>=20
>=20
> > if ((d & ModRM) && modrm_mod =3D=3D 3) {
> > src.type =3D OP_REG;
> [snip]
> > break;
> > }
> > src.type =3D OP_MEM;
> >=20
>=20
> So src.type is OP_MEM and not OP_REG... is it what you want ?
Sorry, in fact it is OP_REG, and it is correct...
Laurent
--=20
----------------- Lau...@bu... ------------------
"La perfection est atteinte non quand il ne reste rien =C3=A0
ajouter mais quand il ne reste rien =C3=A0 enlever." Saint Exup=C3=A9ry
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X