nested VMX + unrelated qemu bug

DISCUSSION Bernhard M. Wiedemann 3 participants 4 messages Jul 14, 2011 – Jul 18, 2011 KVM

Share & tools

Bernhard M. Wiedemann

author

2011-07-14 15:32 UTC #0 lore raw

Hi,

I tried nested VMX on Xeon E5630 and it worked really well with the Kernel from avi's git and 0.14.0 (with modprobe kvm-intel nested=1)

but in the process I found that qemu built from
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
crashed when started with -m 3600 or more
while booting into openSUSE-11.3 where 0.14.0 worked well (even with 5GB)

./x86_64-softmmu/qemu-system-x86_64 -drive file=opensuse-113-64.img,if=virtio,boot=on -m 3600 -serial stdio -vnc :9 Could not open option rom 'extboot.bin': No such file or directory
doing fast boot
Creating device nodes with udev
Trying manual resume from /dev/vda1
Invoking userspace resume from /dev/vda1
resume: libgcrypt version: 1.4.4
Trying manual resume from /dev/vda1
Invoking in-kernel resume from /dev/vda1
Waiting for device /dev/vda2 to appear: ok
fsck from util-linux-ng 2.17.2
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/vda2
/dev/vda2: recovering journal
/dev/vda2: clean, 62553/230608 files, 449938/922112 blocks
fsck succeeded. Mounting root device read-write.
Mounting root /dev/vda2
mount -o rw,acl,user_xattr -t ext4 /dev/vda2 /root

Bad ram offset 1009cc000
Aborted

Ciao
Bernhard M. Wiedemann

Alexander Graf

2011-07-16 07:53 UTC #1 lore raw

Quoted 29 lines · Bernhard M. Wiedemann

Hi,
I tried nested VMX on Xeon E5630 and it worked really well with the Kernel from avi's git and 0.14.0 (with modprobe kvm-intel nested=1)
but in the process I found that qemu built from
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
crashed when started with -m 3600 or more
while booting into openSUSE-11.3 where 0.14.0 worked well (even with 5GB)
./x86_64-softmmu/qemu-system-x86_64 -drive file=opensuse-113-64.img,if=virtio,boot=on -m 3600 -serial stdio -vnc :9 Could not open option rom 'extboot.bin': No such file or directory
doing fast boot
Creating device nodes with udev
Trying manual resume from /dev/vda1
Invoking userspace resume from /dev/vda1
resume: libgcrypt version: 1.4.4
Trying manual resume from /dev/vda1
Invoking in-kernel resume from /dev/vda1
Waiting for device /dev/vda2 to appear: ok
fsck from util-linux-ng 2.17.2
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/vda2
/dev/vda2: recovering journal
/dev/vda2: clean, 62553/230608 files, 449938/922112 blocks
fsck succeeded. Mounting root device read-write.
Mounting root /dev/vda2
mount -o rw,acl,user_xattr -t ext4 /dev/vda2 /root

Quoted 2 lines

Bad ram offset 1009cc000
Aborted

Ah, the infamous memory map bug.

Anthony, could you please pull the xen-next branch so this one finally gets fixed? The following patch should resolve that issue:

commit f221e5ac378feea71d9857ddaa40f829c511742f

Author: Stefano Stabellini <[email protected]>
Date:   Mon Jun 27 18:26:06 2011 +0100

qemu_ram_ptr_length: take ram_addr_t as arguments

qemu_ram_ptr_length should take ram_addr_t as argument rather than target_phys_addr_t because is doing comparisons with RAMBlock addresses.

cpu_physical_memory_map should create a ram_addr_t address to pass to qemu_ram_ptr_length from PhysPageDesc phys_offset.

Remove code after abort() in qemu_ram_ptr_length.

Otherwise, Blue - as you do have commit rights as well - Anthony seems to be rather busy these days. Could you please jump in and commit the outstanding pull requests from maintainers?

Alex

Blue Swirl

2011-07-16 16:26 UTC #2 lore raw

Quoted 48 lines · Alexander Graf

Quoted 29 lines · Bernhard M. Wiedemann
Hi,
I tried nested VMX on Xeon E5630 and it worked really well with the Kernel from avi's git and 0.14.0 (with modprobe kvm-intel nested=1)
but in the process I found that qemu built from
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
crashed when started with -m 3600 or more
while booting into openSUSE-11.3 where 0.14.0 worked well (even with 5GB)
./x86_64-softmmu/qemu-system-x86_64 -drive file=opensuse-113-64.img,if=virtio,boot=on -m 3600 -serial stdio -vnc :9 Could not open option rom 'extboot.bin': No such file or directory
doing fast boot
Creating device nodes with udev
Trying manual resume from /dev/vda1
Invoking userspace resume from /dev/vda1
resume: libgcrypt version: 1.4.4
Trying manual resume from /dev/vda1
Invoking in-kernel resume from /dev/vda1
Waiting for device /dev/vda2 to appear: ok
fsck from util-linux-ng 2.17.2
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/vda2
/dev/vda2: recovering journal
/dev/vda2: clean, 62553/230608 files, 449938/922112 blocks
fsck succeeded. Mounting root device read-write.
Mounting root /dev/vda2
mount -o rw,acl,user_xattr -t ext4 /dev/vda2 /root
Quoted 2 lines
Bad ram offset 1009cc000
Aborted
Ah, the infamous memory map bug.
Anthony, could you please pull the xen-next branch so this one finally gets fixed? The following patch should resolve that issue:
commit f221e5ac378feea71d9857ddaa40f829c511742f
Author: Stefano Stabellini <[email protected]>
Date: Mon Jun 27 18:26:06 2011 +0100
qemu_ram_ptr_length: take ram_addr_t as arguments
qemu_ram_ptr_length should take ram_addr_t as argument rather than target_phys_addr_t because is doing comparisons with RAMBlock addresses.

Quoted 7 lines

cpu_physical_memory_map should create a ram_addr_t address to pass to qemu_ram_ptr_length from PhysPageDesc phys_offset.
Remove code after abort() in qemu_ram_ptr_length.
Otherwise, Blue - as you do have commit rights as well - Anthony seems to be rather busy these days. Could you please jump in and commit the outstanding pull requests from maintainers?

The pull would break build:
LINK alpha-softmmu/qemu-system-alpha
../xen_console.o: In function `con_init':
/src/qemu/hw/xen_console.c:208: undefined reference to `xenstore_store_pv_console_info'

Alexander Graf

2011-07-18 07:23 UTC #3 lore raw

Quoted 55 lines · Blue Swirl

Quoted 54 lines · Alexander Graf
Quoted 29 lines · Bernhard M. Wiedemann
Hi,
I tried nested VMX on Xeon E5630 and it worked really well with the Kernel from avi's git and 0.14.0 (with modprobe kvm-intel nested=1)
but in the process I found that qemu built from
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
crashed when started with -m 3600 or more
while booting into openSUSE-11.3 where 0.14.0 worked well (even with 5GB)
./x86_64-softmmu/qemu-system-x86_64 -drive file=opensuse-113-64.img,if=virtio,boot=on -m 3600 -serial stdio -vnc :9 Could not open option rom 'extboot.bin': No such file or directory
doing fast boot
Creating device nodes with udev
Trying manual resume from /dev/vda1
Invoking userspace resume from /dev/vda1
resume: libgcrypt version: 1.4.4
Trying manual resume from /dev/vda1
Invoking in-kernel resume from /dev/vda1
Waiting for device /dev/vda2 to appear: ok
fsck from util-linux-ng 2.17.2
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/vda2
/dev/vda2: recovering journal
/dev/vda2: clean, 62553/230608 files, 449938/922112 blocks
fsck succeeded. Mounting root device read-write.
Mounting root /dev/vda2
mount -o rw,acl,user_xattr -t ext4 /dev/vda2 /root
Quoted 2 lines
Bad ram offset 1009cc000
Aborted
Ah, the infamous memory map bug.
Anthony, could you please pull the xen-next branch so this one finally gets fixed? The following patch should resolve that issue:
commit f221e5ac378feea71d9857ddaa40f829c511742f
Author: Stefano Stabellini <[email protected]>
Date:   Mon Jun 27 18:26:06 2011 +0100
qemu_ram_ptr_length: take ram_addr_t as arguments
qemu_ram_ptr_length should take ram_addr_t as argument rather than target_phys_addr_t because is doing comparisons with RAMBlock addresses.
cpu_physical_memory_map should create a ram_addr_t address to pass to qemu_ram_ptr_length from PhysPageDesc phys_offset.
Remove code after abort() in qemu_ram_ptr_length.

Quoted 7 lines

Quoted 1 line
Otherwise, Blue - as you do have commit rights as well - Anthony seems to be rather busy these days. Could you please jump in and commit the outstanding pull requests from maintainers?
The pull would break build:
LINK alpha-softmmu/qemu-system-alpha
../xen_console.o: In function `con_init':
/src/qemu/hw/xen_console.c:208: undefined reference to `xenstore_store_pv_console_info'

ARGH :(

...

I've squashed the following patch into the offending patch now and rebased everything on current HEAD (same URL, I don't think it's worth it to respam the ML with another almost identical pull request)

xen-stub.c +4 -0

index a4f35a1..efe2ab5 100644
@@ -9,6 +9,10 @@
 #include "qemu-common.h"
 #include "hw/xen.h"
 
+void xenstore_store_pv_console_info(int i, CharDriverState *chr)
+{
+}
+
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 {
     return -1;

Alex