* nested VMX + unrelated qemu bug @ 2011-07-14 15:22 Bernhard M. Wiedemann 2011-07-16 7:53 ` Alexander Graf 0 siblings, 1 reply; 4+ messages in thread From: Bernhard M. Wiedemann @ 2011-07-14 15:22 UTC (permalink / raw) To: kvm 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nested VMX + unrelated qemu bug 2011-07-14 15:22 nested VMX + unrelated qemu bug Bernhard M. Wiedemann @ 2011-07-16 7:53 ` Alexander Graf 2011-07-16 16:26 ` Blue Swirl 0 siblings, 1 reply; 4+ messages in thread From: Alexander Graf @ 2011-07-16 7:53 UTC (permalink / raw) To: Bernhard M.Wiedemann Cc: Blue Swirl, qemu-devel@nongnu.org Developers, kvm@vger.kernel.org list 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nested VMX + unrelated qemu bug 2011-07-16 7:53 ` Alexander Graf @ 2011-07-16 16:26 ` Blue Swirl 2011-07-18 7:23 ` Alexander Graf 0 siblings, 1 reply; 4+ messages in thread From: Blue Swirl @ 2011-07-16 16:26 UTC (permalink / raw) To: Alexander Graf Cc: Bernhard M.Wiedemann, kvm@vger.kernel.org list, qemu-devel@nongnu.org Developers, Anthony Liguori 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' ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nested VMX + unrelated qemu bug 2011-07-16 16:26 ` Blue Swirl @ 2011-07-18 7:23 ` Alexander Graf 0 siblings, 0 replies; 4+ messages in thread From: Alexander Graf @ 2011-07-18 7:23 UTC (permalink / raw) To: Blue Swirl Cc: Bernhard M.Wiedemann, kvm@vger.kernel.org list, qemu-devel@nongnu.org Developers, Anthony Liguori, Stefano Stabellini 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-07-18 7:23 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-07-14 15:22 nested VMX + unrelated qemu bug Bernhard M. Wiedemann 2011-07-16 7:53 ` Alexander Graf 2011-07-16 16:26 ` Blue Swirl 2011-07-18 7:23 ` Alexander Graf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox