Re: [ANNOUNCE] kvm-88 release
On 07/13/2009 04:32 AM, Avi Kivity wrote: On 07/12/2009 09:43 PM, John Rousseau wrote: Losing -vga std allowed the guest to boot. Attached patch fixes it for me. It does as well for me. Acked-by: John Rousseau jrrouss...@gmail.com Thanks much! -John -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-88 release
On 07/12/2009 09:31 AM, Avi Kivity wrote: kvm-87 wasn't so hot due to networking not working with rtl8139 and e1000. So kvm-88 fixes that and brings a bunch of new features (resizable sdl windows, multiboot, x2apic, and more). Enjoy. Does anyone have this working with FC11? I installed FC11 on a new laptop, replacing my old FC9-running laptop last week and I have been unable to run my Vista guest since: # /usr/local/bin/qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 1536M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap1 -vga std -full-screen -smp 2 -usb -usbdevice tablet Executing /etc/qemu-ifup Bringing up tap1 for bridged mode... Adding tap1 to br0... Bad ram offset 60909fff Aborted I've been running this guest since ~kvm-75 on FC9. Dropping the smp, usb and full-screen options doesn't help. The crash is after the cylon Windows startup bar but before the login screen. Host is FC11 x86_64, 2.6.29.4-167.fc11.x86_64. Intel P8700. 4GB memory. Guest is Vista Ultimate 64. An added bonus is that the crash leaves Xorg in 640x480 resolution. I've also seen just a seg fault instead of the Bad ram error. gdb reports the following if this is at all helpful: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x77cf5910 (LWP 3577)] 0x0035a7c81b3b in memset () from /lib64/libc.so.6 (gdb) where #0 0x0035a7c81b3b in memset () from /lib64/libc.so.6 #1 0x004324a1 in pthread_attr_setdetachstate () #2 0x0052873b in pthread_attr_setdetachstate () #3 0x00528873 in pthread_attr_setdetachstate () #4 0x00528a16 in pthread_attr_setdetachstate () #5 0x0035a880686a in start_thread () from /lib64/libpthread.so.0 #6 0x0035a7cde25d in clone () from /lib64/libc.so.6 #7 0x in ?? () (gdb) info threads 3 Thread 0x7683a910 (LWP 3578) 0x0035a880e778 in pread64 () from /lib64/libpthread.so.0 * 2 Thread 0x77cf5910 (LWP 3577) 0x0035a7c81b3b in memset () from /lib64/libc.so.6 1 Thread 0x77d4a6f0 (LWP 3564) 0x0035a880d934 in __lll_lock_wait () from /lib64/libpthread.so.0 Thanks -John -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-88 release
On 07/12/2009 11:13 AM, Avi Kivity wrote: On 07/12/2009 06:06 PM, John Rousseau wrote: # /usr/local/bin/qemu-system-x86_64 -hda /home/jrr/vista-x86_64.img -m 1536M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap1 -vga std -full-screen -smp 2 -usb -usbdevice tablet Can you try without -full-screen? Without -vga std? Losing -vga std allowed the guest to boot. Note -usbdevice tablet is only eating your cpu. Cool. Removed. Try ./configure --disable-strip. (gdb) set args -hda /home/jrr/vista-x86_64.img -m 1536M -net nic,vlan=0,macaddr=52:54:00:12:32:00 -net tap,vlan=0,ifname=tap1 -vga std ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x77cf5910 (LWP 2792)] 0x0035a7c81b3b in memset () from /lib64/libc.so.6 (gdb) where #0 0x0035a7c81b3b in memset () from /lib64/libc.so.6 #1 0x004324a1 in vbe_ioport_write_data (opaque=0x13da5e8, addr=value optimized out, val=value optimized out) at /home/jrr/build/kvm/kvm-88/hw/vga.c:629 #2 0x0052873b in kvm_outw (data=value optimized out, addr=value optimized out, opaque=value optimized out) at /home/jrr/build/kvm/kvm-88/qemu-kvm.c:155 #3 handle_io (data=value optimized out, addr=value optimized out, opaque=value optimized out) at /home/jrr/build/kvm/kvm-88/qemu-kvm.c:877 #4 kvm_run (data=value optimized out, addr=value optimized out, opaque=value optimized out) at /home/jrr/build/kvm/kvm-88/qemu-kvm.c:1103 #5 0x00528873 in kvm_cpu_exec (env=0x0) at /home/jrr/build/kvm/kvm-88/qemu-kvm.c:1825 #6 0x00528a16 in kvm_main_loop_cpu (env=value optimized out) at /home/jrr/build/kvm/kvm-88/qemu-kvm.c:2007 #7 ap_main_loop (env=value optimized out) at /home/jrr/build/kvm/kvm-88/qemu-kvm.c:2044 #8 0x0035a880686a in start_thread () from /lib64/libpthread.so.0 #9 0x0035a7cde25d in clone () from /lib64/libc.so.6 #10 0x in ?? () Thanks -John -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/12] kvm: qemu: device-assignment: cleanup irq assignment error messages
Mark McLoughlin wrote:
Replace perror() usage with sane error message.
Signed-off-by: Mark McLoughlin [EMAIL PROTECTED]
---
qemu/hw/device-assignment.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index 2b2ef68..b39617a 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -473,9 +473,10 @@ void assigned_dev_update_irq(PCIDevice *d)
assigned_irq_data.host_irq = assigned_dev-real_device.irq;
r = kvm_assign_irq(kvm_context, assigned_irq_data);
if (r 0) {
-perror(assigned_dev_update_irq);
-fprintf(stderr, Are you assigning a device
-that shares IRQ with some other device?\n);
+fprintf(stderr, Failed to assign irq for \%s\: %s\n,
+adev-name, strerror(-r));
+fprintf(stderr, Perhaps you re you assigning a device
Typo.
+that shares IRQ with another device?\n);
pci_unregister_device(assigned_dev-dev);
/* FIXME: Delete node from list */
continue;
-John
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: MMU: avoid creation of unreachable pages in the shadow
Marcelo Tosatti wrote: On Tue, Nov 25, 2008 at 01:27:27PM -0500, John Rousseau wrote: Marcelo Tosatti wrote: It is possible for a shadow page to have a parent link pointing to a freed page. When zapping a high level table, kvm_mmu_page_unlink_children fails to remove the parent_pte link. For that to happen, the child must be unreachable via the shadow tree, which can happen in shadow_walk_entry if the guest pte was modified in between walk() and fetch(). Remove the parent pte reference in such case. Possible cause for oops in bug #2217430. I'll apply this to the code that I'm testing, but with my change to 2.6.27, kvm-79 and Avi's patch from bug #2217430, I haven't seen the problem again. I still have been testing with oos_shadow=0, which I'll get rid of now. John, Please use the attached patch in addition (and drop Avi's). What is the application set you use to reproduce these issues (that you mentioned in the bugtrack) ? I've been running the vista guest continually since Wednesday with variable load (mostly idle) and it's been completely stable. I'm not sure if it's the move to 2.6.27, kvm-79 or your patches, but your patches didn't seem to hurt. :-) -John -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: MMU: avoid creation of unreachable pages in the shadow
Marcelo Tosatti wrote: It is possible for a shadow page to have a parent link pointing to a freed page. When zapping a high level table, kvm_mmu_page_unlink_children fails to remove the parent_pte link. For that to happen, the child must be unreachable via the shadow tree, which can happen in shadow_walk_entry if the guest pte was modified in between walk() and fetch(). Remove the parent pte reference in such case. Possible cause for oops in bug #2217430. I'll apply this to the code that I'm testing, but with my change to 2.6.27, kvm-79 and Avi's patch from bug #2217430, I haven't seen the problem again. I still have been testing with oos_shadow=0, which I'll get rid of now. Thanks -John -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: MMU: avoid creation of unreachable pages in the shadow
Marcelo Tosatti wrote: On Tue, Nov 25, 2008 at 01:27:27PM -0500, John Rousseau wrote: Marcelo Tosatti wrote: It is possible for a shadow page to have a parent link pointing to a freed page. When zapping a high level table, kvm_mmu_page_unlink_children fails to remove the parent_pte link. For that to happen, the child must be unreachable via the shadow tree, which can happen in shadow_walk_entry if the guest pte was modified in between walk() and fetch(). Remove the parent pte reference in such case. Possible cause for oops in bug #2217430. I'll apply this to the code that I'm testing, but with my change to 2.6.27, kvm-79 and Avi's patch from bug #2217430, I haven't seen the problem again. I still have been testing with oos_shadow=0, which I'll get rid of now. John, Please use the attached patch in addition (and drop Avi's). What is the application set you use to reproduce these issues (that you mentioned in the bugtrack) ? Just Vista desktop apps (Firefox, word, SMB via Windows explorer). Patching now. Thanks -John -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest kvm.git versus Windows Vista?
walt wrote: walt wrote: ... So, does anyone have Vista working on recent kvm.git? Yes. I do, but only because I forgot to load the kvm-amd kernel module. I guess that means I'm really running Vista on plain qemu, and not on kvm at all. Is that correct? It appears to be. How slow is it? (Yes, I know it's Vista). I haven't been able to run a stable Vista (64 bit) since kvm-75. -John -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
