nested VMX + unrelated qemu bug

nested VMX + unrelated qemu bug

[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

Bad ram offset 1009cc000
Aborted


Ciao
Bernhard M. Wiedemann

Re: nested VMX + unrelated qemu bug

[Alexander Graf]

On 14.07.2011, at 17:22, Bernhard M. Wiedemann wrote:

> 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

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 <stefano.stabellini@eu.citrix.com>
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

Re: nested VMX + unrelated qemu bug

[Blue Swirl]

On Sat, Jul 16, 2011 at 10:53 AM, Alexander Graf <agraf@suse.de> wrote:
>
> On 14.07.2011, at 17:22, Bernhard M. Wiedemann wrote:
>
>> 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
>
> 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 <stefano.stabellini@eu.citrix.com>
> 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?

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'

Re: nested VMX + unrelated qemu bug

[Alexander Graf]

On 16.07.2011, at 18:26, Blue Swirl wrote:

> On Sat, Jul 16, 2011 at 10:53 AM, Alexander Graf <agraf@suse.de> wrote:
>> 
>> On 14.07.2011, at 17:22, Bernhard M. Wiedemann wrote:
>> 
>>> 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
>> 
>> 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 <stefano.stabellini@eu.citrix.com>
>> 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?
> 
> 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)


diff --git a/xen-stub.c b/xen-stub.c
index a4f35a1..efe2ab5 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -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