Re: Out-dated Qemu link on http://www.linux-kvm.org/Main_page
2011/2/24 Philipp Hahn h...@univention.de: Hello, On http://www.linux-kvm.org/page/Main_Page in the Common External Pages sections the QEMU link links to the out-dated http://www.nongnu.org/qemu page, which just shows the info, that the site has moved to http://wiki.qemu.org/Index.html. (This internally redirects to http://wiki.qemu.org/Main_Page, so linking that page might be better or even just http://wiki.qemu.org/) FYI, everyone has write permissions to the wiki - you just need to create an account. I also sometimes fix stuff in the wiki, when I spot outdated things like the one you just found. Unfortunately, there doesn't seem to be a big interest in keeping the information on the wiki up to date, so I think most of the updates are done by users of the wiki. Best regards Kenni -- 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: PCI Passthrough, error: The driver 'pci-stub' is occupying your device 0000:08:06.2
2011/2/7 Daniel P. Berrange berra...@redhat.com: On Sat, Feb 05, 2011 at 04:34:01PM +, James Neave wrote: Hi, I'm trying to pass a NOVA-T-500 TV Tuner card through to a gust VM. I'm getting the error The driver 'pci-stub' is occupying your device :08:06.2 This is a rather misleading error message. It is *expected* that pci-stub will occupy the device. Unfortunately the rest of the error messages QEMU is printing aren't much help either, but ultimately something is returning -EBUSY in the PCI device assign step James, as far as I remember, I had the same issue when I set up my system. Looking at my current (working) boot-script, apparently I've added a 4th line which removes the pci-stub again as a workaroundand it works: echo 0016 /sys/bus/pci/drivers/pci-stub/new_id echo :04:08.0 /sys/bus/pci/drivers/ivtv/unbind echo :04:08.0 /sys/bus/pci/drivers/pci-stub/bind echo 0016 /sys/bus/pci/drivers/pci-stub/remove_id Best regards Kenni -- 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: USB Passthrough 1.1 performance problem...
2010/12/14 Erik Brakkee e...@brakkee.org: Daniel P. Berrange wrote: On Tue, Dec 14, 2010 at 12:55:04PM +0100, Kenni Lund wrote: 2010/12/14 Erik Brakkeee...@brakkee.org: From: Kenni Lundke...@kelu.dk 2010/12/14 Erik Brakkeee...@brakkee.org: From: Kenni Lundke...@kelu.dk Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500 might work now? Passthrough of a PVR-500 has been working for a long time. I've been running with passthrough of a PVR-500 in my HTPC, since November/December 2009...so it should work with any recent kernel and any recent version of qemu-kvm you can find today - No patching needed. The only issue I had with the PVR-500 card, was when *I* didn't free up the shared interrupts...once I fixed that, it just worked. How did you free up those shared interrupts then? I tried different slots but always get conflicts with the USB irqs. I did an unbind of the conflicting device (eg. disabled it). I moved the PVR-500 card around in the different slots and once I got a conflict with the integrated sound card, I left the PVR-500 card in that slot (it's a headless machine, so no need for sound) and configured unbind of the sound card at boot time. On my old system I think it was conflicting with one of the USB controllers as well, but it didn't really matter, as I only lost a few of the ports on the back of the computer for that particular USB controller - I still had plenty of USB ports left and if I really needed more ports, I could just plug in an extra USB PCI card. My /etc/rc.local boot script looks like the following today: -- #Remove HDA conflicting with ivtv1 echo :00:1b.0 /sys/bus/pci/drivers/HDA\ Intel/unbind # ivtv0 echo 0016 /sys/bus/pci/drivers/pci-stub/new_id echo :04:08.0 /sys/bus/pci/drivers/ivtv/unbind echo :04:08.0 /sys/bus/pci/drivers/pci-stub/bind echo 0016 /sys/bus/pci/drivers/pci-stub/remove_id # ivtv1 echo 0016 /sys/bus/pci/drivers/pci-stub/new_id echo :04:09.0 /sys/bus/pci/drivers/ivtv/unbind echo :04:09.0 /sys/bus/pci/drivers/pci-stub/bind echo 0016 /sys/bus/pci/drivers/pci-stub/remove_id I did not try unbinding the usb device so I can also try that. I don'.t understand what is happening with the 0016. I configured the pci card in kvm and I believe kvm does the binding to pci-stub in recent versions. Where is the 0016%oming from? Okay, qemu-kvm might do it today, I don't know - I haven't changed that script for the past year. But are you sure that it's not libvirt/virsh/virt-manager which does that for you? If you use the managed=yes attribute on thehostdev in libvirt XML, then libvirt will automatically do the pcistub bind/unbind, followed by a device reset at guest startup the reverse at shutdown. If you have conflicting devices on the bus though, libvirt won't attempt to unbind them, unless you had also explicitly assigned all those conflicting devices to the same guest. Daniel I definitely have to try again (right now having some stability problems on the server that I am debugging). The shared IRQs are as follows: 16: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 252995 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb8, ivtv0 19: 58281 0 0 0 0 0 0 0 IO-APIC-fasteoi ata_piix, ata_piix, uhci_hcd:usb5, uhci_hcd:usb7, ivtv1 21: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 23: 713 6906 0 76919 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 So I have IRQ sharing with usb1, usb8, usb5, usb7. Uffand your ata HDD controller. I guess i was much luckier than you are, my ivtv0 didn't conflict at all and ivtv1 only conflicted with USB. I have also read that ehci refers to USB 2.0 and uhci to USB 1.1 is that correct? Anyway, how would I now identify the USB PCI devices that I would need to unbind to get rid of the sharing with the USB ports? Play around with: lspci -v lspci -n lsusb -v lsusb -t You can also just start by unbinding the first one and take note when you hit the right ones...once you unbind one, it will disappear from cat /proc/interrupts. When you're down to having only ivtv0 on one interrupt and only ivtv1 on another interrupt, then you're ready to bind with pci-stub and boot your guest. It also doesn't really matter in which slot I put the PVR-500 card because both cards share IRQs with USB in all cases. You also have your conflicting ata controller to take into consideration. I don't remember if ata_piix and ata_piix is IDE only, if it is, you might not even use it. Otherwise it might be easier for you to run qemu-kvm
Re: USB Passthrough 1.1 performance problem...
2010/12/12 Erik Brakkee e...@brakkee.org: Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500 might work now? Passthrough of a PVR-500 has been working for a long time. I've been running with passthrough of a PVR-500 in my HTPC, since November/December 2009...so it should work with any recent kernel and any recent version of qemu-kvm you can find today - No patching needed. The only issue I had with the PVR-500 card, was when *I* didn't free up the shared interrupts...once I fixed that, it just worked. On the other hand, I've never had success with passthrough of USB. I've spend a bunch of time trying to get various USB cards to work with passthrough, I even purchased 3 USB cards, just to test USB passthrough with different brands, interfaces and versions (PCI, PCIe, USB 2.0, USB 3.0, etc). I gave up on that 5 months ago - http://article.gmane.org/gmane.comp.emulators.kvm.devel/56719 What version is this and where can I get this for opensuse? I can't remember if I started out with the PVR-500 card with 0.11 or 0.12 ...I think it was 0.11...but anyway, you'll hopefully not run with such an old version today, so any version should work. Best regards Kenni -- 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: USB Passthrough 1.1 performance problem...
2010/12/14 Erik Brakkee e...@brakkee.org: From: Kenni Lund ke...@kelu.dk Does this mean I have a chance now that PCI passthrough of my WinTV PVR-500 might work now? Passthrough of a PVR-500 has been working for a long time. I've been running with passthrough of a PVR-500 in my HTPC, since November/December 2009...so it should work with any recent kernel and any recent version of qemu-kvm you can find today - No patching needed. The only issue I had with the PVR-500 card, was when *I* didn't free up the shared interrupts...once I fixed that, it just worked. How did you free up those shared interrupts then? I tried different slots but always get conflicts with the USB irqs. I did an unbind of the conflicting device (eg. disabled it). I moved the PVR-500 card around in the different slots and once I got a conflict with the integrated sound card, I left the PVR-500 card in that slot (it's a headless machine, so no need for sound) and configured unbind of the sound card at boot time. On my old system I think it was conflicting with one of the USB controllers as well, but it didn't really matter, as I only lost a few of the ports on the back of the computer for that particular USB controller - I still had plenty of USB ports left and if I really needed more ports, I could just plug in an extra USB PCI card. My /etc/rc.local boot script looks like the following today: -- #Remove HDA conflicting with ivtv1 echo :00:1b.0 /sys/bus/pci/drivers/HDA\ Intel/unbind # ivtv0 echo 0016 /sys/bus/pci/drivers/pci-stub/new_id echo :04:08.0 /sys/bus/pci/drivers/ivtv/unbind echo :04:08.0 /sys/bus/pci/drivers/pci-stub/bind echo 0016 /sys/bus/pci/drivers/pci-stub/remove_id # ivtv1 echo 0016 /sys/bus/pci/drivers/pci-stub/new_id echo :04:09.0 /sys/bus/pci/drivers/ivtv/unbind echo :04:09.0 /sys/bus/pci/drivers/pci-stub/bind echo 0016 /sys/bus/pci/drivers/pci-stub/remove_id -- Best regards Kenni -- 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: HAL type for Win2003 Server on recent KVM versions?
2010/11/18 Avi Kivity a...@redhat.com: On 11/18/2010 12:58 AM, Kenni Lund wrote: Hi I'm about to move a couple of virtual machines from a Fedora 11 system to a new server with a more recent operating system and newer version of KVM, etc. One of the guests is a Windows Server 2003 Standard SP2, which is currently running with the ACPI Multiprocessor PC HAL. Considering moving to RHEL, I've been reading the virtualization documentation for RHEL 6.0, which says that I need to set HAL to Standard PC when installing a new Win2003 guest. Since my current guest has been running perfectly fine for a long time with its current HAL, I was wondering if the system will become unstable, unbootable or what the disadvantage will be, if I move the guest to for example RHEL 6.0, without reinstalling or upgrading the guest to select another HAL mode? On the other hand, it seems like I can upgrade from the current ACPI Multiprocessor PC into Standard PC, but I'm not sure if I'll gain anything by trying this. I suggest using the default HAL, whatever it is. That's what everyone else is using so you get the best tested configuration. Thanks Avi, ACPI Multiprocessor PC was/is the default HAL, I didn't change anything when the system was originally installed. I'm curious why the RHEL 6 documentation claims that you actively need to select the Standard PC HAL on installation, if it's not even the recommended/preferred HAL...(?): Windows 2003 requires a specific computer type in order to install properly on a fully-virtualized guest. This needs to be specified at the beginning of the installation process.[1] [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization/sect-Virtualization_Windows2003.html Best regards Kenni -- 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: HAL type for Win2003 Server on recent KVM versions?
2010/11/18 Cole Robinson crobi...@redhat.com: On 11/18/2010 09:05 AM, Kenni Lund wrote: I'm curious why the RHEL 6 documentation claims that you actively need to select the Standard PC HAL on installation, if it's not even the recommended/preferred HAL...(?): Windows 2003 requires a specific computer type in order to install properly on a fully-virtualized guest. This needs to be specified at the beginning of the installation process.[1] [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization/sect-Virtualization_Windows2003.html I'm pretty sure that was incorrectly copied over from the RHEL5 xen documentation. The docs people have been informed so it should be fixed soon-ish. Perfect, thanks! :) Best regards Kenni -- 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
HAL type for Win2003 Server on recent KVM versions?
Hi I'm about to move a couple of virtual machines from a Fedora 11 system to a new server with a more recent operating system and newer version of KVM, etc. One of the guests is a Windows Server 2003 Standard SP2, which is currently running with the ACPI Multiprocessor PC HAL. Considering moving to RHEL, I've been reading the virtualization documentation for RHEL 6.0, which says that I need to set HAL to Standard PC when installing a new Win2003 guest. Since my current guest has been running perfectly fine for a long time with its current HAL, I was wondering if the system will become unstable, unbootable or what the disadvantage will be, if I move the guest to for example RHEL 6.0, without reinstalling or upgrading the guest to select another HAL mode? On the other hand, it seems like I can upgrade from the current ACPI Multiprocessor PC into Standard PC, but I'm not sure if I'll gain anything by trying this. Thanks in advance.. Best regards Kenni -- 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: iPhone with KVM?
2010/10/12 Jun Koi junkoi2...@gmail.com: hi, i have a guest Windows on KVM, with iTunes installed on that. then i let my guest to have direct access to my iPhone connecting to my physical USB port, using usb_add command. but i got a serious problem: usb_add doesnt seem to work, as my guest Windows never sees my iPhone. The USB emulaiton in qemu/qemu-kvm doesn't support USB 2.0 at the moment, only USB 1.1. so it seems that giving guest Windows the direct access to USB port is not enough. any idea why this happens? any solution? Wait for USB 2.0 support to arrive or try to do PCI Passthrough of a USB card/controller. I have yet to come across a USB card/controller that actually works with PCI passthrough, though :/ Best regards Kenni -- 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: Using 1920x1080 resolution with kvm
2010/10/10 Aniruddha mailingdotl...@gmail.com: I would like to use a resolution 1920x1080 for my Windows XP Guest. Leave KVM at the default resolution (eg. don't specify any resolution), activate remote desktop in Windows XP and connect with rdesktop or some other RDP client to the guest. The RDP protocol will give you the resolution you request and will also be much more responsive/faster than if you do VNC to a KVM guest running at some high native resolution. VNC to a Windows guest should only be needed for installing Windows and for debugging when Windows doesn't boot. Best regards Kenni -- 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: PCI Device Assignment status
2010/9/3 Rodrigo Campos rodr...@sdfg.com.ar: Hi! I wanted to know the status of PCI device assignment. As far as I can see in the webpage and in the mailing list, it seems to be working ok if you have VT-d support on the motherboard and cpu. But if it isn't too much trouble, I wanted some confirmation about this, since I'm not sure and I don't want to buy hardware to test this when there is no way it's going to work :) It highly depends on what you want to passthrough...if it's some well-known SR-IOV server NIC, then sure, it will probably work. If you want to passthrough various PCI devices in a regular desktop system or workstation, then forget it. I've been playing that various PCI devices in a regular desktop system game for the last 8 months on my HTPC. I've been running with both stable versions of KVM as well as self-compiled versions from git during this time. The tests I have performed were done on two different VT-d capable boards (a Gigabyte EQ45M-S2 and a Intel DQ57TM). I've tried to passthrough 2 PCI TV tuners (Hauppauge 500 + Hauppauge 1300), 2 PCI USB 2.0 cards (can't remember the brands), 1 onboard USB controller (on a Gigabyte EQ45M-S2), and finally a PCI Express USB 3.0 card (Asrock). The only device which works correctly, is the Hauppauge 500 card. I bought the USB 3.0 card ONLY to see if it would help with a PCI Express card instead of the regular PCI cards I had tested...but no, it didn't change anything. In my tests the cards almost works in some cases - eg. the card gets correctly initialized in the guest and you can start to use it, but then you'll have timing issues, driver crashes, client program crashes, etc. etc. Right now I'm awaiting RHEL 6 to see if passthrough has been improved here. If not, then as much as I would hate it, I'll switch back to Xen...people could passthrough all kinds of weird PCI cards 5 years ago with paravirtualization on Xen. Even though I see Xen as a dying platform, at least it works. Best Regards Kenni -- 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
USB card passthrough - Has anyone succeeded?
Hi list I did some KVM testing with help from Alexander Graf and Chris Wright back in March, trying to passthrough various USB 2.0 PCI cards and onboard Intel USB hubs. I never got it to work completely, I ended up with some timing issues or similar, causing artifacts in the picture from a connected DVB-T USB tuner (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/45027/focus=49764). Since then I've upgraded my system to a more recent VT-d capable system; an Intel DQ57TM motherboard with a Core i5 670 CPU. In addition I bought a PCIe USB card (Asrock USB 3.0 PCI Express) to see if the MSI/MSI-X support on the PCIe card would change anything. Unfortunately the new PCIe card doesn't work either - now I just get a xhci_hcd :00:07.0: WARN urb submitted to disabled ep error on the client side, when I try to access the DVB-T device (which btw is registered correctly in the guest and its driver is also loaded correctly). This makes me wonder: Has anyone actually succeeded in doing passthrough of a internal/external USB 2.0/3.0 card with KVM+VT-d? If yes, with what hardware? Thanks Kenni -- 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: PCI passthrough resource remapping
2010/3/31 Chris Wright chr...@redhat.com: * Kenni Lund (ke...@kelu.dk) wrote: 2010/3/31 Chris Wright chr...@redhat.com: So I suppose I'll need to get rid of this shared IRQ before I can conclude anything on the patch in git. Hmm, is there some cleaver way of fixing this in Linux, or do I have to fix it by changing BIOS IRQ settings, disabling hardware and/or moving the hardware around in various PCI slots? The way I typically work around this is simply unbinding the driver from the device in the host (and thus freeing the irq). Doh...anyway, I went all the way, found a USB-PS2 adaptor, disabled the onboard USB controller and PATA controller in BIOS, and now got kvm_assigned_intx_device for all 4 IRQs :) A little extreme...but hey, that works ;-) I'm still curious what's going on w/ your PCI card and the irq routing. Something is suspect. I'll not be able to do any further testing for the next two weeks, but if you want me to perform some tests, test patches etc., just write what you want me to do and I'll do it in two weeks. Best Regards Kenni -- 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: PCI passthrough resource remapping
2010/3/31 Kenni Lund ke...@kelu.dk: Booting the guest and tuning to a DVB-T channel _works_ !!! :-D Thanks a lot for your help...I have one more question, though: If I have two devices (like the ivtv tuner and the USB card) and they share an IRQ, if I then assign BOTH of them to the same guest, will it then work? Alexander, the patch works, I hope to see it in a stable release in the near future ;) Unfortunately, I have a correction to this :( It _almost_ works. I had some video/audio artifacts which I though was caused by bad reception, but after switching the DVB-T tuner back and forth between the PCI USB card and a laptop, it got clear to me, that this was a passthrough issue. I get no errors in dmesg on the host or in the guest. I recorded a short videoclip which illustrates the issue: https://docs.google.com/leaf?id=0B-_nZameGeN-NDk4YzQ3N2EtMmEzMi00NTU4LWFjMjgtNzkxMzcxYzg2MTM1hl=en Best Regards Kenni -- 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: PCI passthrough resource remapping
2010/3/31 Alexander Graf ag...@suse.de: Kenni Lund wrote: 2010/3/31 Kenni Lund ke...@kelu.dk: Booting the guest and tuning to a DVB-T channel _works_ !!! :-D Thanks a lot for your help...I have one more question, though: If I have two devices (like the ivtv tuner and the USB card) and they share an IRQ, if I then assign BOTH of them to the same guest, will it then work? Alexander, the patch works, I hope to see it in a stable release in the near future ;) Unfortunately, I have a correction to this :( It _almost_ works. I had some video/audio artifacts which I though was caused by bad reception, but after switching the DVB-T tuner back and forth between the PCI USB card and a laptop, it got clear to me, that this was a passthrough issue. I get no errors in dmesg on the host or in the guest. I recorded a short videoclip which illustrates the issue: https://docs.google.com/leaf?id=0B-_nZameGeN-NDk4YzQ3N2EtMmEzMi00NTU4LWFjMjgtNzkxMzcxYzg2MTM1hl=en Hrm, I'm not sure these would be related to the small BAR region patch. It looks more like a timing issue. For what it's worth, I quickly tried to passthrough one of the onboard USB controllers instead (Intel Corporation 82801JD/DO (ICH10 Family), which is also affected by the 4k limitation). It improves the artifact problems, bringing the artifacts down to one artifact every 5 seconds. I'll be back in ~1½ week, please tell me if you want me to test something when I get back. Thanks for your help :) Best Regards Kenni -- 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: PCI passthrough resource remapping
2010/3/30 Chris Wright chr...@redhat.com: * Kenni Lund (ke...@kelu.dk) wrote: Client dmesg: http://pastebin.com/uNG4QK5j Host dmesg: http://pastebin.com/jZu3WKZW I just verified it and I do get the call trace in the host (which disables IRQ 19, used by the PCI USB card), exactly at the same second It looks like IRQ 19 is shared between the ehci controller and the ivtv tuner. What do you see in /proc/interrupts on the host (before you unbind and after you bind to pci stub)? Ahh, and even if the ivtv module is not loaded, I will still have a shared IRQ, right? I didn't see ivtv in /proc/interrupts before, as I unload the ivtv driver on boot in /etc/rc.local, before unbinding the ivtv tuner and binding it to pci stub. (the ivtv tuner is normally assigned to the same guest, but not now while testing the PCI USB card). If I don't unload (and unbind/bind) the ivtv driver/tuner on boot in /etc/local, I get the following in /proc/interrupts on a clean boot: http://pastebin.com/SFQj58LC If I now unbind and bind the PCI USB card to pci stub, I get no changes in /proc/interrupts. So I suppose I'll need to get rid of this shared IRQ before I can conclude anything on the patch in git. Hmm, is there some cleaver way of fixing this in Linux, or do I have to fix it by changing BIOS IRQ settings, disabling hardware and/or moving the hardware around in various PCI slots? Best Regards Kenni -- 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: PCI passthrough resource remapping
2010/3/31 Alexander Graf ag...@suse.de: On 31.03.2010, at 00:27, Kenni Lund wrote: 2010/3/30 Chris Wright chr...@redhat.com: * Kenni Lund (ke...@kelu.dk) wrote: Client dmesg: http://pastebin.com/uNG4QK5j Host dmesg: http://pastebin.com/jZu3WKZW I just verified it and I do get the call trace in the host (which disables IRQ 19, used by the PCI USB card), exactly at the same second It looks like IRQ 19 is shared between the ehci controller and the ivtv tuner. What do you see in /proc/interrupts on the host (before you unbind and after you bind to pci stub)? Ahh, and even if the ivtv module is not loaded, I will still have a shared IRQ, right? I didn't see ivtv in /proc/interrupts before, as I unload the ivtv driver on boot in /etc/rc.local, before unbinding the ivtv tuner and binding it to pci stub. (the ivtv tuner is normally assigned to the same guest, but not now while testing the PCI USB card). If I don't unload (and unbind/bind) the ivtv driver/tuner on boot in /etc/local, I get the following in /proc/interrupts on a clean boot: http://pastebin.com/SFQj58LC If I now unbind and bind the PCI USB card to pci stub, I get no changes in /proc/interrupts. So I suppose I'll need to get rid of this shared IRQ before I can conclude anything on the patch in git. Hmm, is there some cleaver way of fixing this in Linux, or do I have to fix it by changing BIOS IRQ settings, disabling hardware and/or moving the hardware around in various PCI slots? The easiest thing coming to mind is to unplug the ivtv card for now. It's really only to verify that the patch does something useful :-). This was not sufficient. Same issue with the ivtv card unplugged...if I interpret the content of /proc/interrupt correctly, the USB PCI cards uses 4 IRQs and out of these three IRQs are still shared with other components. The card uses IRQ 16, 18, 19, 20: pci-stub :02:01.0: PCI INT B - GSI 18 (level, low) - IRQ 18 pci-stub :02:01.1: PCI INT C - GSI 16 (level, low) - IRQ 16 pci-stub :02:01.2: PCI INT D - GSI 20 (level, low) - IRQ 20 pci-stub :02:01.3: PCI INT A - GSI 19 (level, low) - IRQ 19 Only IRQ 20 gets kvm_assigned_intx_device after unbinding+binding+qemu-kvm launch: interrupts before: http://pastebin.com/DdJEv29z interrupts after: http://pastebin.com/zasWEZsL It seems like i still have shared IRQs with the onboard USB controller as well as the PATA controller. In the BIOS i have the option of setting the IRQ of PCI Card 1 and PCI Card 2. I tried changing these into IRQ 10 and 11 (which are free according to /proc/interrupts), but it changed absolutely nothing in /proc/interrupts after booting(?) :-( Any kind of hint which could lead me in hte right direction, would be highly appreciated...thanks. Best Regards Kenni -- 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: PCI passthrough resource remapping
2010/3/31 Chris Wright chr...@redhat.com: So I suppose I'll need to get rid of this shared IRQ before I can conclude anything on the patch in git. Hmm, is there some cleaver way of fixing this in Linux, or do I have to fix it by changing BIOS IRQ settings, disabling hardware and/or moving the hardware around in various PCI slots? The way I typically work around this is simply unbinding the driver from the device in the host (and thus freeing the irq). Doh...anyway, I went all the way, found a USB-PS2 adaptor, disabled the onboard USB controller and PATA controller in BIOS, and now got kvm_assigned_intx_device for all 4 IRQs :) Booting the guest and tuning to a DVB-T channel _works_ !!! :-D Thanks a lot for your help...I have one more question, though: If I have two devices (like the ivtv tuner and the USB card) and they share an IRQ, if I then assign BOTH of them to the same guest, will it then work? Alexander, the patch works, I hope to see it in a stable release in the near future ;) Best Regards Kenni -- 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: PCI passthrough resource remapping
2010/1/9 Alexander Graf ag...@suse.de: On 09.01.2010, at 03:45, Ryan C. Underwood wrote: I have a multifunction PCI device that I'd like to pass through to KVM. In order to do that, I'm reading that the PCI memory region must be 4K-page aligned and the PCI memory resources itself must also be exact multiples of 4K pages. I have added the following on my kernel command line: reassign_resources reassigndev=08:09.0,08:09.1,08:09.2,08:09.3,08:09.4 But I don't know if it has any effect. The resources are still not sized in 4K pages. Also, this seems to screw up the last device. I submitted a patch to qemu-kvm recently that got rid of that limitation. Please try out if the current git head works for you. Alex-- I just upgraded to kernel 2.6.32.10 with qemu-kvm 0.12.3 and I still get the following error when trying to pass through a dedicated PCI USB card: Unable to assign device: PCI region 0 at address 0xe9403000 has size 0x100, which is not a multiple of 4K Error initializing device pci-assign Didn't the above patch make it into qemu-kvm? I don't know why, but I was under the impression that this was fixed when I upgraded to qemu-kvm 0.12.3. It's only in qemu-kvm.git. Maybe it should go into qemu-kvm-0.12.4 if there is one That would be highly appriciated...with the current USB support in QEMU, PCI passthrough is the only way to get USB 2.0 support. I've bought two dedicated PCI USB cards for this, but none of them works due to the above limitation. Perhaps a developer can comment on this? Are there any plans on including this patch in the stable releases in the near future? Thanks :) Best Regards Kenni Lund -- 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: PCI passthrough resource remapping
2010/3/29 Alexander Graf ag...@suse.de: On 29.03.2010, at 19:23, Kenni Lund wrote: 2010/1/9 Alexander Graf ag...@suse.de: On 09.01.2010, at 03:45, Ryan C. Underwood wrote: I have a multifunction PCI device that I'd like to pass through to KVM. In order to do that, I'm reading that the PCI memory region must be 4K-page aligned and the PCI memory resources itself must also be exact multiples of 4K pages. I have added the following on my kernel command line: reassign_resources reassigndev=08:09.0,08:09.1,08:09.2,08:09.3,08:09.4 But I don't know if it has any effect. The resources are still not sized in 4K pages. Also, this seems to screw up the last device. I submitted a patch to qemu-kvm recently that got rid of that limitation. Please try out if the current git head works for you. Alex-- I just upgraded to kernel 2.6.32.10 with qemu-kvm 0.12.3 and I still get the following error when trying to pass through a dedicated PCI USB card: Unable to assign device: PCI region 0 at address 0xe9403000 has size 0x100, which is not a multiple of 4K Error initializing device pci-assign Didn't the above patch make it into qemu-kvm? I don't know why, but I was under the impression that this was fixed when I upgraded to qemu-kvm 0.12.3. It's only in qemu-kvm.git. Maybe it should go into qemu-kvm-0.12.4 if there is one That would be highly appriciated...with the current USB support in QEMU, PCI passthrough is the only way to get USB 2.0 support. I've bought two dedicated PCI USB cards for this, but none of them works due to the above limitation. Perhaps a developer can comment on this? Are there any plans on including this patch in the stable releases in the near future? Please first try out to build the current git snapshot of qemu-kvm. If it works properly for you then I agree that we should take this into 0.12-stable. I wrote the support for a card that still didn't work even with this patch. So having someone say it makes things work for him is definitely a must :-). Sure, I have compiled the current git snapshot and performed some tests...It's at least mostly working, so I'm a bit unsure if this is a bug related to this or to something else. Here's my test results on trying to passthrough a PCI USB card (I've copy-pasted the text below into http://pastebin.com/8RJE36wG in case formatting is lost below): qemu-kvm complete command line: qemu-kvm -usbdevice tablet -net nic,macaddr=52:54:00:00:00:01,model=virtio -net tap,ifname=tap0 -vnc :1 -smp 2 -m 2048 -cdrom /data/server/Linux/mythbuntu-9.10-desktop-amd64.iso -drive file=/data/virtualization/01_Mythbuntu.img,if=virtio,boot=on -boot c -localtime -daemonize -pcidevice host=02:01.0 -pcidevice host=02:01.1 -pcidevice host=02:01.2 -pcidevice host=02:01.3 -monitor unix:/var/run/kvm/01.socket,server,nowait -k da uname -a on host Linux mediaserver 2.6.32-ARCH #1 SMP PREEMPT Fri Mar 26 02:03:53 CET 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux Exact kernel version is 2.6.32.10. lspci -v on host, only for the USB PCI card: 02:01.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ALi Corporation ASRock 939Dual-SATA2 Motherboard Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 18 Memory at e940 (32-bit, non-prefetchable) [size=4K] Capabilities: [60] Power Management version 2 Kernel driver in use: pci-stub Kernel modules: ohci-hcd 02:01.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ALi Corporation ASRock 939Dual-SATA2 Motherboard Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at e9401000 (32-bit, non-prefetchable) [size=4K] Capabilities: [60] Power Management version 2 Kernel driver in use: pci-stub Kernel modules: ohci-hcd 02:01.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: ALi Corporation ASRock 939Dual-SATA2 Motherboard Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 20 Memory at e9402000 (32-bit, non-prefetchable) [size=4K] Capabilities: [60] Power Management version 2 Kernel driver in use: pci-stub Kernel modules: ohci-hcd 02:01.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: Device 2020: Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19 Memory at e9403000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=0090 Kernel driver in use: pci-stub Kernel modules: ehci-hcd Commands on host used to prepare PCI USB card: echo 10b9 5237 /sys/bus/pci/drivers/pci-stub/new_id echo :02:01.0 /sys/bus/pci/drivers/ohci_hcd/unbind echo :02
Re: PCI passthrough resource remapping
2010/3/30 Chris Wright chr...@redhat.com: * Alexander Graf (ag...@suse.de) wrote: On 30.03.2010, at 01:00, Kenni Lund wrote: 2010/3/29 Alexander Graf ag...@suse.de: On 29.03.2010, at 19:23, Kenni Lund wrote: 2010/1/9 Alexander Graf ag...@suse.de: On 09.01.2010, at 03:45, Ryan C. Underwood wrote: I have a multifunction PCI device that I'd like to pass through to KVM. In order to do that, I'm reading that the PCI memory region must be 4K-page aligned and the PCI memory resources itself must also be exact multiples of 4K pages. I have added the following on my kernel command line: reassign_resources reassigndev=08:09.0,08:09.1,08:09.2,08:09.3,08:09.4 But I don't know if it has any effect. The resources are still not sized in 4K pages. Also, this seems to screw up the last device. I submitted a patch to qemu-kvm recently that got rid of that limitation. Please try out if the current git head works for you. Alex-- I just upgraded to kernel 2.6.32.10 with qemu-kvm 0.12.3 and I still get the following error when trying to pass through a dedicated PCI USB card: Unable to assign device: PCI region 0 at address 0xe9403000 has size 0x100, which is not a multiple of 4K Error initializing device pci-assign Didn't the above patch make it into qemu-kvm? I don't know why, but I was under the impression that this was fixed when I upgraded to qemu-kvm 0.12.3. It's only in qemu-kvm.git. Maybe it should go into qemu-kvm-0.12.4 if there is one That would be highly appriciated...with the current USB support in QEMU, PCI passthrough is the only way to get USB 2.0 support. I've bought two dedicated PCI USB cards for this, but none of them works due to the above limitation. Perhaps a developer can comment on this? Are there any plans on including this patch in the stable releases in the near future? Please first try out to build the current git snapshot of qemu-kvm. If it works properly for you then I agree that we should take this into 0.12-stable. I wrote the support for a card that still didn't work even with this patch. So having someone say it makes things work for him is definitely a must :-). Sure, I have compiled the current git snapshot and performed some tests...It's at least mostly working, so I'm a bit unsure if this is a bug related to this or to something else. Chris, any idea on this? Looks like something's going wrong with function assignment. Hmm, one thing that sticks out to me is the debug port. Kenni, can you post full dmesg on both host and guest, nothing is obviously broken (and in fact the guest should never see the debug port). Uploaded here: Client dmesg: http://pastebin.com/uNG4QK5j Host dmesg: http://pastebin.com/jZu3WKZW I just verified it and I do get the call trace in the host (which disables IRQ 19, used by the PCI USB card), exactly at the same second I ask the DVB-T tuner to view a channel in the guest. Thanks.. Best Regards Kenni Lund -- 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: PCI passthrough resource remapping
2010/1/9 Alexander Graf ag...@suse.de: On 09.01.2010, at 03:45, Ryan C. Underwood wrote: I have a multifunction PCI device that I'd like to pass through to KVM. In order to do that, I'm reading that the PCI memory region must be 4K-page aligned and the PCI memory resources itself must also be exact multiples of 4K pages. I have added the following on my kernel command line: reassign_resources reassigndev=08:09.0,08:09.1,08:09.2,08:09.3,08:09.4 But I don't know if it has any effect. The resources are still not sized in 4K pages. Also, this seems to screw up the last device. I submitted a patch to qemu-kvm recently that got rid of that limitation. Please try out if the current git head works for you. Alex-- I just upgraded to kernel 2.6.32.10 with qemu-kvm 0.12.3 and I still get the following error when trying to pass through a dedicated PCI USB card: Unable to assign device: PCI region 0 at address 0xe9403000 has size 0x100, which is not a multiple of 4K Error initializing device pci-assign Didn't the above patch make it into qemu-kvm? I don't know why, but I was under the impression that this was fixed when I upgraded to qemu-kvm 0.12.3. Thanks Best Regards Kenni -- 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: Tracking KVM development
2010/3/22 Asdo a...@shiftmail.org: I've looked at libvirt a bit, and I fail at seeing the attraction. I think I will stay with plain qemu-kvm, unless there are some very compelling reasons for going down the libvirt route. Virsh (uses libvirt) is almost irreplaceable for us... How do you start and stop virtual machines easily, get a list of the running ones... How do you ensure a virtual machine is never started twice? (would obviously have disastrous results on the filesystem) How do you connect on-demand to the graphics of the VM from your laptop, with a good security so that only the system administrator can do that? (virt-viewer provides very easy support for this, tunnelling VNC graphics over SSH, you connect by specifying the name of the host and the name of the VM... just great!) I fully agree...I started out by starting the VMs by entering the kvm-command directly in a terminal. Then I decided to put it in a shell script, so I didn't have to type the same things over and over again. Then I needed a way to easily start, stop and restart the machines, so I wrote another script for this. Then I decided to extend it with some more functionality, allowing me to list running machines and ensure that machines weren't run more than once. Then I decided to extended the script to parse *.conf files, which allowed me to automatically configure VMs through one *.conf file per VM. Then I hacked some more functionality into the script and ...now I've essentially hacked together some more or less ugly shell script for handling my VMs. After spending a bit of time with Fedora and libvirt/virsh, I feel quite stupid - this solves, if not all, then most of my problems. Right now I'm just waiting for RHEL/CentOS 6.0 to get released, so i can get rid of my ugly shell script and make the switch to libvirt/virsh for good :) Best Regards Kenni Lund -- 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: PCI Videocard passthrough
2010/2/27 Jan Češčut jan.ces...@kgs.si: Has anyone already tried passing through to a certain VM a pci videocard (using Intel VT-d) ? I have a VguardCard for videocontrolle which should run inside a VM (Windows XP). Go give it a try, only NICs are officially supported by KVM, but other devices should work as well (except from graphics cards). I have a system running in which I'm passing through two PCI video grabbers / TV tuners and it works just fine. I suppose your VGuard Card works very similar to my video grabbers, your card will probably just require some more bandwidth. Best Regards Kenni Lund -- 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: Digium TDM410 passthrought to KVM VM trixbox
(forgot to CC list on my last reply) 2010/2/22 raincatsd...@me.com: I followed the tutorial How to assign devices with KVM VT-d. Giving the command dmesg | grep-e-e dmar IOMMU prompt does not return anything! Ok, if dmesg | grep -e DMAR -e IOMMU doesn't give you any output, it doesn't make sense to perform any further tests untill you have fixed this. It will not work without this. The Linux distribution is Ubuntu server 9.10 with different kernel test: 1. the original 2.6.31-19-server ; 2. 2.6.31-19-server ricompiled with mudules Support for DMA Remapping Devices;Enable DMA Remapping Devices;PCI Stub driver;Support for Interrupt Remapping ; 3. 2.6.32.8 ricompiled with mudules Support for DMA Remapping Devices;Enable DMA Remapping Devices;PCI Stub driver;Support for Interrupt Remapping ; In that case you're down to two problems, AFAIK: 1. Your hardware (your chipset) doesn't support VT-d. 2. VT-d support is not enabled in BIOS, not supported in BIOS or BIOS implementation is buggy. What motherboard do you have? Best Regards Kenni Lund -- 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: Digium TDM410 passthrought to KVM VM trixbox
2010/2/22 Chris Wright chr...@sous-sol.org: * raincatsd...@me.com (raincatsd...@me.com) wrote: This is my motherboard: http://h10025.www1.hp.com/ewfrf/wc/document?docname=c01324212lc=encc=cadlc=enproduct=3691066 The virtualization technology is enabled from bios and KVM (not QEMU) virtual machine work correctly! VT-x is needed for that (CPU extensions supporting hardware assisted virtual machine, and shows up as vmx in cpuinfo). VT-d is needed for doing device assignment (adds an IOMMU to the chipset), and according to your dmesg grep is not available/enabled. Looks like you have the G33[1] chipset with ICH9R[2] which does not have an IOMMU. I've updated the KVM VT-d wikipage with a short section on VT-d support. Best regards Kenni Lund -- 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: Digium TDM410 passthrought to KVM VM trixbox
2010/2/23 Paolo Rivetti raincatsd...@me.com: Now I realize that my solution is wrong because of my ignorance (VT-x and VT-d). Practically there is another solution to communicate with a PCI card with a virtual machine? Or should I completely change the system? If you want to use KVM you'll need VT-d. Xen supports paravirtual PCI passthrough which doesn't require VT-d. I don't know about Vmware, etc. Best Regards Kenni Lund -- 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: Passthrough PCI video capture card
2010/2/5 Ameya Pandit cont...@ameyapandit.com: SNIP Please find below logs for more information. I want to passthrough this PCI card to one of the VM. Any suggestions how to do this? You need to have a system with IOMMU support, eg. Intel VT-d or AMD I/O Virtualization Technology (IOMMU). Your chipset needs to support this, it has nothing to do with virtualization support of your CPU. If you have a proper system, you can use the following guide for passthrough: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM Best Regards Kenni Lund -- 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: Install NetBSD 5.0.1/Sparc64 on Qemu falied
2010/1/31 dixlor name dix...@gmail.com: # wget ftp://iso.netbsd.org/pub/NetBSD/iso/5.0.1/sparc64cd-5.0.1.iso # qemu-img create -f qcow2 NETBSD.qcow2 12G; # qemu-system-sparc64 -hda ./NETBSD.qcow2 -cdrom sparc64cd-5.0.1.iso; In QEMU: 0 boot cdrom NetBSD IEEE 1275 Bootblock Invalid superblock magic byte-load: exception caught! ok 0 That's all :( Well, this issue doesn't really have anything to do with KVM (which is x86/x86_64 only), your Sparc64 issue is pure QEMU... That said, Sparc64 is not supported yet, according to the status page of QEMU: http://www.qemu.org/status.html In generel, you'll most likely get more qualified answers if you ask such questions in a forum dealing with QEMU emulation, for example the official QEMU forum: http://qemu-forum.ipi.fi/ Best Regards Kenni Lund -- 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: compiling kvm on ubuntu 9.10
2010/1/30 Puja Gupta pmgupta@gmail.com: Can anyone tell me exact steps compile kvm on ubuntu 9.10.. If you just want to install and use KVM on Ubuntu, follow Ubuntus own guide: https://help.ubuntu.com/community/KVM If you want to compile it manually: http://www.linux-kvm.org/page/HOWTO1 Best Regards Kenni Lund -- 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: KVM problems with Xeon L5530
2010/1/28 Matteo Ghezzi tenyos...@gmail.com: SNIP I've tried starting the old vmachines on the new hardware but if I enable kvm acceleration in qemu I got a black screen via vnc, and the Enable kvm in qemu? KVM should always be enabled in Arch, when you run qemu-kvm. You're not running [qemu-executable] --enable-kvm from the qemu package, right? Last time I checked, the KVM support in upstream qemu wasn't very good and gave me various errors. Make sure you have the qemu-kvm package installed and not the qemu package (which also has KVM support). Best Regards Kenni Lund -- 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: How to properly turn off guest VM on server shutdown?
2010/1/26 Markus Breitländer breitlaen...@stud.fh-dortmund.de:
Hello Glennie,
Am 26.01.2010 14:46, schrieb Glennie Vignarajah:
Le 24/01/2010 vers 18:16, dans le message intitulé Re: How to properly turn
off guest VM on server shutdown?, Markus Breitländer(Markus Breitländer
breitlaen...@stud.fh-dortmund.de) a écrit:
Hi!
Hello;
Does anyone have sample scripts for this job?
#!/bin/bash
CONNECT_STRING=qemu:///system
for MACHINE in $(virsh -c $CONNECT_STRING list | awk '/running$/ {print
$2}') ; do
virsh -c $CONNECT_STRING shutdown $MACHINE
done
sleep 600
This code will shutdown all runnning hosts with acpi en enabled.
I haven't tested it under windows Seven, but under win 2003, you have modify:
* Using regedit the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Windows and set the value ShutdownWarningDialogTimeout to
dword:0001 (this will force shutdown even if users are connected)
AND
* Goto Control Pannel, admin tools and double-click Local security
settings
* Expand Local policies and click on Security Options (left window pan)
* On the right side, locate Shutdown: Allow system to be shutdown... and
enable the option(this allows to powerdown on ctr-alt-del screen.
HTH
I was thinking about a script that doesn't use virsh.
I suppose you can start your guest with
-monitor unix:/${SOCKETFILE},server,nowait
and then do something like:
socat - unix-connect:${SOCKETFILE} EOF
system_powerdown
EOF
Best Regards
Kenni Lund
--
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: PCIe device pass-through - No IOMMU, Failed to deassign device error
2010/1/26 Chris Wright chr...@sous-sol.org: Again, VT (or VT-x) isn't the same as VT-d. So to be sure, you can grep dmesg for DMAR and IOMMU to verify that the chipset actually has VT-d support, that it's enabled, and that it's not broken (there are quite a few broken BIOS out there that case the IOMMU to be unusable). dmesg | egrep (DMAR|IOMMU) This information should _really_ be added to the wiki at http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM Knowing this, it's quite easy for a user to determine if his system has VT-d support, _before_ following the guide, compiling own kernel, setting up qemu-kvm, unbinding and rebinding PCI devices, just to have qemu-kvm 0.12.2 tell him that the system has no IOMMU (much better than 0.12.1, agreed, but it's a bit late in the process to find out :)) Can someone with write permissions to the wiki please add this? Best Regards Kenni Lund -- 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: PCIe device pass-through - No IOMMU, Failed to deassign device error
2010/1/26 Kenni Lund ke...@kelu.dk: 2010/1/26 Chris Wright chr...@sous-sol.org: Again, VT (or VT-x) isn't the same as VT-d. So to be sure, you can grep dmesg for DMAR and IOMMU to verify that the chipset actually has VT-d support, that it's enabled, and that it's not broken (there are quite a few broken BIOS out there that case the IOMMU to be unusable). dmesg | egrep (DMAR|IOMMU) This information should _really_ be added to the wiki at http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM Knowing this, it's quite easy for a user to determine if his system has VT-d support, _before_ following the guide, compiling own kernel, setting up qemu-kvm, unbinding and rebinding PCI devices, just to have qemu-kvm 0.12.2 tell him that the system has no IOMMU (much better than 0.12.1, agreed, but it's a bit late in the process to find out :)) Doh, I didn't consider if the kernel compilation probably were needed to give any output - nevertheless, I still think this should be added to the wiki, even if it's the case. Perhaps a short text describing what you should look for. Best Regards Kenni Lund -- 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
Best strategy for use of swap?
Hi I was wondering; Does it make any sense to use swap inside guests? Wouldn't it give better performance to just skip swap entirely in the guest, assign it more memory and then increase the swap size on the host? Writing to swap on the host side doesn't have the overhead of the virtio layer, Qcow2 filesystem or an underlying host filesystem. And at the same time, KSM can decrease the overall memory usage on the host, which I suppose will lower the risk of the host using swap at all. Are there any disadvantages to this or would this be the prefered way of using swap on a KVM-based system? Thanks Best Regards Kenni Lund -- 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: MS Window virtio drivers certification status
2010/1/11 Yan Vugenfirer yvuge...@redhat.com: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Saul Tamari Sent: Monday, January 11, 2010 6:26 PM To: Yan Vugenfirer Cc: kvm Subject: Re: MS Window virtio drivers certification status Hi, Are you talking about both network block drivers? [YV] Yes. Only difference for block - Windows XP certified driver wasn't release with RHEL5.4. It should be in RHEL 5.5. Will these block drivers for XP be optimized in terms of performance or will they, like the current ones, still be slower than the regular IDE emulated block devices? [1] [1] http://article.gmane.org/gmane.comp.emulators.kvm.devel/40762 Best Regards Kenni -- 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: SIGTERM to qemu-kvm process destroys qcow2 image?
2009/12/17 Kevin Wolf kw...@redhat.com: Am 17.12.2009 11:23, schrieb Avi Kivity: On 12/17/2009 11:38 AM, Kenni Lund wrote: 2009/12/17 Avi Kivitya...@redhat.com: On 12/17/2009 02:52 AM, Kenni Lund wrote: Yesterday I entered an invalid boot device as an argument to my qemu-kvm command for my Windows XP machine, causing an error about a missing boot device in the qemu BIOS/POST. As I didn't have any filesystems mounted inside the virtual machine (since it was stuck at the BIOS asking for a device to boot), I did a kill $pid, fixed the boot device in the qemu-kvm command and tried booting again...but with no luck, whatever I try now with qemu-kvm gives me the error: qemu: could not open disk image /data/virtualization/WindowsXP.img And qemu-img (check, convert, etc) gives me: qemu-img: Could not open 'WindowsXP.img' Can you post the first 4K of the image? It shouldn't contain private data, but go over it (or don't post) if you sensitive information there. 4K dump attached. Seems fine. Kevin can you take a look? Agreed, the dump looks fine. Even qcow2_open succeeds if I just use this header as a qcow2 file. You have a backing file. Do qemu-img info and qemu-img check like it? So I'd definitely have a look at the backing file. It's almost the only thing that can go wrong after qcow2_open. qemu-img doesn't have known problems with backing files in general, but it does have problems with missing (or broken) backing files. Kenni, could you check if your backing file is still alive? /tmp doesn't sound like a safe place for images. If it still exists in the right location (/tmp/WindowsXP.img.backup) and it is qcow2, can you please attach the first 4k of the backing file? Kevin Huh? Backing file? Is that the same as a base image? Eg. a write protected image on which other images can be based? If so, I'm quite confused...this should be a standalone image created with a command like qemu-img create -f WindowsXP.img 50G half a year ago on kvm 8x. I don't use libvirt/virt-manager etc. I start qemu-kvm directly from a homemade bash script. I don't have any /tmp/WindowsXP.img.backup file, and I would never put stuff inside /tmp, especially not images, they belong to /data/virtualization/ on my server and nowhere else If the image needs another image in /tmp/WindowsXP.img.backup I can see why it doesn't work, but I have _no_ idea why or how this file was created (?!??) - even if I was doing a test with base-images, I would do it directly in /data/virtualization/ and never in /tmp/ Best Regards Kenni Lund -- 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: SIGTERM to qemu-kvm process destroys qcow2 image?
2009/12/18 Avi Kivity a...@redhat.com: On 12/18/2009 04:13 PM, Kenni Lund wrote: The '/tmp' was prefixed by qemu-img, the actual path is 'WindowsXP.img.backup', so on your setup qemu-img would look for it in /data/virtualization/. If the image needs another image in /tmp/WindowsXP.img.backup I can see why it doesn't work, but I have _no_ idea why or how this file was created (?!??) - even if I was doing a test with base-images, I would do it directly in /data/virtualization/ and never in /tmp/ If it isn't there you can try to create it (qemu-img create /data/virtualization/WindowsXP.img.backup 3145728). If no data was actually stored there, your image will be recovered. Thanks, this explains the whole thing - this is own mistake, I move all the backups into a subdirectory, I didn't know that I had based the image on a backup-image, bad design decision on my part. I'm sorry for the false alarm, thanks a lot for your help :) Best Regards Kenni Lund -- 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: SIGTERM to qemu-kvm process destroys qcow2 image?
2009/12/17 Avi Kivity a...@redhat.com: On 12/17/2009 02:52 AM, Kenni Lund wrote: Yesterday I entered an invalid boot device as an argument to my qemu-kvm command for my Windows XP machine, causing an error about a missing boot device in the qemu BIOS/POST. As I didn't have any filesystems mounted inside the virtual machine (since it was stuck at the BIOS asking for a device to boot), I did a kill $pid, fixed the boot device in the qemu-kvm command and tried booting again...but with no luck, whatever I try now with qemu-kvm gives me the error: qemu: could not open disk image /data/virtualization/WindowsXP.img And qemu-img (check, convert, etc) gives me: qemu-img: Could not open 'WindowsXP.img' Can you post the first 4K of the image? It shouldn't contain private data, but go over it (or don't post) if you sensitive information there. 4K dump attached. Best Regards Kenni Lund WindowsXP.img_4k_dump Description: Binary data
SIGTERM to qemu-kvm process destroys qcow2 image?
Hi Sorry if this is a stupid question, but is it expected behaviour that a qcow2 image will/can get damaged by killing the qemu-kvm process with a SIGTERM signal? I would expect data on filesystems within the virtual machine to potentially get damaged if it's in use, but I though that the qemu-kvm process would take care of finishing its writes correctly to the qcow2 image before shutting down, ensuring the integrity of the qcow2 image. Yesterday I entered an invalid boot device as an argument to my qemu-kvm command for my Windows XP machine, causing an error about a missing boot device in the qemu BIOS/POST. As I didn't have any filesystems mounted inside the virtual machine (since it was stuck at the BIOS asking for a device to boot), I did a kill $pid, fixed the boot device in the qemu-kvm command and tried booting again...but with no luck, whatever I try now with qemu-kvm gives me the error: qemu: could not open disk image /data/virtualization/WindowsXP.img And qemu-img (check, convert, etc) gives me: qemu-img: Could not open 'WindowsXP.img' Is this expected behaviour? Luckily I do have backups of the most important data on this machine, I'm just happy this didn't happen to any of my critical machines :-/ I'm on qemu-kvm 0.11.0 with kernel modules from 2.6.31.6. Best Regards Kenni Lund -- 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
PCI passthrough of TV-tuners with VT-d
Hi While considering upgrading my MythTV backend to a VT-d capable system, I'm trying to figure out if it would be possible to utilize PCI passthrough with KVM. As far as I understand the wiki page on How to assign devices with VT-d [1] and various posts on mailing lists, then all conventional PCI devices should (hopefully) work, as long as they don't share an IRQ with another device, and IF they share a IRQ, the device must be MSI capable - is this assumption correct? I know that graphics cards are special, but I'm only interested in TV tuners in my specific case. I don't know if anyone has tested TV tuners on KVM, which perhaps makes it a hard question, but would you expect that a regular PCI TV Tuner with onboard MPEG2 encoder (not PCI Express, not MSI-capable, using a unique IRQ) would work? If it makes any difference, the TV tuners are all Hauppauge PVR-150/250, recognized by lspci as Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder. Thanks in advance :) Best Regards Kenni Lund [1] http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM -- 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: guest .img files
2009/10/17 Lynn Wilborn l...@hotrodpc.com: I have a windows 2003 server guest that's been registered with MS, and it probably won't let me do that many more times. So I want to save the guest, erase fedora, and install centos 5.4 when it comes out. I don't know if this always is the case, but I've done several reinstallations of Windows 2003 and if it won't accept your legal serial, you'll get the option to phone your local MS department and they'll reactivate it so you'll be able to install it on new hardware. Im told I can just copy the .img file of the guest to a network share to back it up, but is there anything I would need to do to have the virt-manager gui on the new OS see it and list it when I copy it back? Does it need to be imported in some way? I don't know if there's a fancier way, but I did it some time ago myself; just backup the image and the corresponding libvirt XML configuration file from /etc/libvirt/qemu/ (or something like that, I don't have access to a Fedora machine at the moment) and copy it back on the new machine. Now restart the libvirtd daemon, to make it load the XML-files and start up virt-manager. FYI: This is a bit off topic as it is not really related to KVM, a better place to ask virt-manager questions would be at the fedora-virt mailing list; https://www.redhat.com/mailman/listinfo/fedora-virt Best Regards Kenni Lund -- 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
KVM crash on kvm-88 + kernel 2.6.30.6
Hi I had a KVM crash today with WinXP Pro SP3 32bit on kvm-88 + kernel 2.6.30.6 (modules from kernel). [ cut here ] WARNING: at arch/x86/kvm/x86.c:204 kvm_queue_exception_e+0x6b/0x80 [kvm]() Hardware name: Latitude D520 Modules linked in: ipv6 i915 drm i2c_algo_bit rfcomm sco bridge stp llc bnep l2cap btusb bluetooth fan usbhid hid fuse snd_seq_dummy tun snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device kvm_intel kvm snd_pcm_oss joydev snd_hda_codec_idt snd_mixer_oss ohci1394 ieee1394 snd_hda_intel arc4 snd_hda_codec snd_hwdep ecb snd_pcm yenta_socket rsrc_nonstatic dell_laptop snd_timer snd soundcore snd_page_alloc uhci_hcd psmouse video thermal output ac iTCO_wdt iTCO_vendor_support wmi processor button iwl3945 ehci_hcd battery usbcore dcdbas i2c_i801 i2c_core intel_agp sg iwlcore rfkill mac80211 led_class agpgart serio_raw evdev cfg80211 slhc b44 ssb pcmcia pcmcia_core mii rtc_cmos rtc_core rtc_lib ext3 jbd mbcache aes_i586 aes_generic xts gf128mul dm_crypt dm_mod sd_mod sr_mod cdrom ata_piix ata_generic pata_acpi libata scsi_mod Pid: 4238, comm: qemu-kvm Not tainted 2.6.30-ARCH #1 Call Trace: [c013b26a] ? warn_slowpath_common+0x7a/0xc0 [f8a3451b] ? kvm_queue_exception_e+0x6b/0x80 [kvm] [c013b2d0] ? warn_slowpath_null+0x20/0x40 [f8a3451b] ? kvm_queue_exception_e+0x6b/0x80 [kvm] [f8a35927] ? kvm_task_switch+0x277/0xc60 [kvm] [f8a3d842] ? mmu_sync_children+0x182/0x340 [kvm] [f8a42015] ? x86_emulate_insn+0x1895/0x3cb0 [kvm] [f8a3ff96] ? x86_decode_insn+0x686/0xd50 [kvm] [f8a654be] ? vmx_fpu_deactivate+0x4e/0x70 [kvm_intel] [f8a66b61] ? handle_task_switch+0x31/0xc0 [kvm_intel] [f8a67161] ? kvm_handle_exit+0xf1/0x200 [kvm_intel] [c012a5a4] ? kunmap_atomic+0x84/0xb0 [c012a55c] ? kunmap_atomic+0x3c/0xb0 [f8a34dcd] ? kvm_arch_vcpu_ioctl_run+0x34d/0xaf0 [kvm] [f8a2ab5e] ? kvm_vcpu_ioctl+0x45e/0x7f0 [kvm] [c0166dba] ? futex_wake+0xfa/0x110 [f8a2a700] ? kvm_vcpu_ioctl+0x0/0x7f0 [kvm] [c01dfcb2] ? vfs_ioctl+0x22/0xa0 [c01dfdb9] ? do_vfs_ioctl+0x89/0x5a0 [c0141bca] ? irq_exit+0x3a/0x90 [c01688fa] ? sys_futex+0xca/0x160 [c01e035e] ? sys_ioctl+0x8e/0xb0 [c0103cb3] ? sysenter_do_call+0x12/0x28 ---[ end trace 82bf054de8a6387e ]--- Misc info: -- The Blue Screen Of Death gave the following error: *** STOP: 0x008E (0xC01D, 0xF7A48D3E, 0xF7C5ECC0, 0x) *** processr.sys - Address F7A48D3E base at F7A47000, DateStamp 48025181 -- Startup command: qemu-kvm -usbdevice tablet -net nic,macaddr=52:55:00:00:00:01,model=rtl8139 -net tap,ifname=tap0 -vnc :1 -smp 2 -m 1024 -cdrom /home/kenni/images/NETKVM-20081229.iso -hda /data/virtualization/winxp.img -boot c -localtime -daemonize -monitor unix:/var/run/kvm/01_winxp.socket,server,nowait -- $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping: 6 cpu MHz : 1995.143 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow bogomips: 3991.54 clflush size: 64 power management: snip -- $ uname -a Linux D520 2.6.30-ARCH #1 SMP PREEMPT Wed Sep 9 12:37:32 UTC 2009 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux -- I don't suppose that this is enough information for you to identify the issue? As I haven't had this crash before, I don't know if I'll see it again...can I do something to collect better debugging information in the future? Perhaps enable kernel memory dump in Windows or something else? Best Regards Kenni Lund -- 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: Binary Windows guest drivers are released
2009/9/25 Vadim Rozenfeld vroze...@redhat.com: On 09/25/2009 12:07 AM, Dor Laor wrote: On 09/24/2009 11:59 PM, Javier Guerra wrote: On Thu, Sep 24, 2009 at 3:38 PM, Kenni Lundke...@kelu.dk wrote: I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in (almost) all cases. Perhaps I've missed something or does the driver still need optimization? very interesting! it seems that IDE wins on all the performance numbers, but VirtIO always has lower CPU utilization. i guess this is guest CPU %, right? it would also be interesting to compare the CPU usage from the host point of view, since a lower 'off-guest' CPU usage is very important for scaling to many guests doing I/O. These drivers are mainly tweaked for win2k3 and win2k8. We once had queue depth settings in the driver, not sure we still have it, Vadim, can you add more info? Dor Windows XP 32-bit virtio block driver was created from our mainline code almost for fun. Not like our mainline code, which is STORPORT oriented, it is a SCSIPORT () mini-port driver. SCSIPORT has never been known as I/O optimized storage stack. SCSIPORT architecture is almost dead officially. Windows XP 32-bit has no support for STORPORT or virtual storage stack. Ok, in that case, wouldn't it be better simply not to build the XP driver and instead put a note somewhere (in the wiki?), saying that it doesn't make sense to use VirtIO on XP due to these reasons? Developing monolithic disk driver, which will sit right on top of virtio-blk PCI device, looks like the one way to have some kind of high throughput storage for Windows XP 32-bit. Ok, since these drivers are targeted Windows Server and XP is getting old, I suppose no efforts will be put into developing such driver, or? Best Regards, Kenni -- 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: Binary Windows guest drivers are released
2009/9/24 Yan Vugenfirer yvuge...@redhat.com: Hello All, I am happy to announce that the Windows guest drivers binaries are released. Thank you, I've been waiting for this for quite a while :) I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in (almost) all cases. Perhaps I've missed something or does the driver still need optimization? I created two raw images of 5GB and attached them to a WinXP SP3 virtual machine with: -drive file=virtio.img,if=virtio -drive file=ide.img,if=ide I installed the VirtIO drivers, rebooted, formatted the new virtual HDDs with NTFS and downloaded IOMeter. Three different test were run; database workload (Default in IOmeter), maximum read throughput and maximum write throughput (settings taken from IOmeter documentation). All results are the average of two individual runs of the test. Each test ran for 3 minutes. -- Typical database workload (default in Iometer: 2kb, 67% read, 33% write, 100% random, 0% sequential) -- Total I/Os per sec: IDE: 86,67 VirtIO: 66,84 Total MBs per second: IDE: 0,17MB/sec VirtIO: 0,13MB/sec Average I/O response time: IDE: 11,59ms VirtIO: 14,96ms Maximum I/O response time: IDE: 177,06ms VirtIO: 244,52ms % CPU Utilization: IDE: 3,15% VirtIO: 2,55% -- Maximum reading throughput (64kb, 100% read, 0% write, 0% random, 100% sequential) -- Total I/Os per sec: IDE: 3266,17 VirtIO: 2694,34 Total MBs per second: IDE: 204,14MB/sec VirtIO: 168,40MB/sec Average I/O response time: IDE: 0,3053ms VirtIO: 0,3710ms Maximum I/O response time: IDE: 210,60ms VirtIO: 180,65ms % CPU Utilization: IDE: 70,4% VirtIO: 55,66% -- Maximum writing throughput (64kb, 0% read, 100% write, 0% random, 100% sequential) -- Total I/Os per sec: IDE: 258,92 VirtIO: 123,69 Total MBs per second: IDE: 16,18MB/sec VirtIO: 7,74MB/sec Average I/O response time: IDE: 3,89ms VirtIO: 8,17ms Maximum I/O response time: IDE: 241,99ms VirtIO: 838,19ms % CPU Utilization: IDE: 8,21% VirtIO: 4,88% This was tested on a Arch Linux host with kernel 2.6.30.6 64bit and kvm-88. One CPU and 2GB of RAM was assigned to the virtual machine. Is this expected behaviour? Thanks again for your effort on the VirtIO drivers :) Best Regards Kenni Lund -- 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: losing mouse location with vnc
2009/9/12 Ross Boylan r...@biostat.ucsf.edu: When I try to use a (Linux) VM via vnc there appear to be two mouse locations at once. One is the pointer displayed on the screen; the other is the shown as a little box by krdc when I select always show local cursor in the krdc menu. It also appears when I use xtightvncviewer. Try using -usbdevice tablet as an argument to the QEMU/KVM executable, it will most likely fix your problem. -- Kenni -- 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: Unable to boot guest on kernel 2.6.29.1 with kvm-84 or kvm-85
Avi Kivity wrote: Kenni Lund wrote: Avi Kivity a...@redhat.com wrote: Kenni Lund wrote: Ok, but as I write in my message, I'm using the KVM modules from the latest upstream kernel, not the kvm-85 modules. According to the KVM download page, http://www.linux-kvm.org/page/Downloads, any kernel above 2.6.25 should work with the latest KVM userspace. This has been true until now in my case, but it breaks with 2.6.29.1 and that's the reason why I'm posting this bug report. Can you try a bisect? Yes, sorry for the late reply. I did the bisect as requested and it returned the following results: # bad: [8d7bff2d72660d9d60aa371ae3d1356bbf329a09] Linux 2.6.29.1 # good: [4a6908a3a050aacc9c3a2f36b276b46c0629ad91] Linux 2.6.28 git bisect start 'v2.6.29.1' 'v2.6.28' '--' 'arch/x86/kvm' 'virt/kvm' # good: [b82091824ee4970adf92d5cd6d57b12273171625] KVM: Prevent trace call into unloaded module text git bisect good b82091824ee4970adf92d5cd6d57b12273171625 # good: [7f59f492da722eb3551bbe1f8f4450a21896f05d] KVM: use cpumask_var_t for cpus_hardware_enabled git bisect good 7f59f492da722eb3551bbe1f8f4450a21896f05d # good: [19de40a8472fa64693eab844911eec277d489f6c] KVM: change KVM to use IOMMU API git bisect good 19de40a8472fa64693eab844911eec277d489f6c # good: [2aaf69dcee864f4fb6402638dd2f263324ac839f] KVM: MMU: Map device MMIO as UC in EPT git bisect good 2aaf69dcee864f4fb6402638dd2f263324ac839f # good: [682edb4c01e690c7c7cd772dbd6f4e0fd74dc572] KVM: Fix assigned devices circular locking dependency git bisect good 682edb4c01e690c7c7cd772dbd6f4e0fd74dc572 # bad: [f438349efb8247cd0c1d453a4131b1f801bf5691] KVM: VMX: Don't allow uninhibited access to EFER on i386 git bisect bad f438349efb8247cd0c1d453a4131b1f801bf5691 # good: [516a1a7e9dc80358030fe01aabb3bedf882db9e2] KVM: VMX: Flush volatile msrs before emulating rdmsr git bisect good 516a1a7e9dc80358030fe01aabb3bedf882db9e2 And the final output: f438349efb8247cd0c1d453a4131b1f801bf5691 is first bad commit commit f438349efb8247cd0c1d453a4131b1f801bf5691 Author: Avi Kivity Date: Thu Mar 26 23:05:03 2009 + KVM: VMX: Don't allow uninhibited access to EFER on i386 upstream commit: 16175a796d061833aacfbd9672235f2d2725df65 vmx_set_msr() does not allow i386 guests to touch EFER, but they can still do so through the default: label in the switch. If they set EFER_LME, they can oops the host. Fix by having EFER access through the normal channel (which will check for EFER_LME) even on i386. Reported-and-tested-by: Benjamin Gilbert Cc: sta...@kernel.org Signed-off-by: Avi Kivity Signed-off-by: Chris Wright :04 04 cf7848d35c136beee6665e67839080d450977af0 0a39980481dd346306b2ac54dbe916741515f1f1 M arch FYI, I also tested 2.6.29.2 and the issue still exists. Do you need more information? Please try the attached patch. It won't help - I reproduced the issue. Instead, try passing the parameter '-cpu qemu32' (or '-cpu qemu64,-nx'). Adding the parameter '-cpu qemu32' (32bit host + 32 bit guest) makes the WinXP guest boot. ...but is this parameter equal to '-no-kvm'? Eg. with emulated CPU? Best Regards Kenni Lund -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo
Re: Unable to boot guest on kernel 2.6.29.1 with kvm-84 or kvm-85
On Thu 23/04/09 23:57 , Bernhard Held bh...@mgpi.de sent: When updating to kernel 2.6.29.1, I'm unable to boot my Windows XP Pro 32bit guest. The problem is consistent (actually on both of my laptops, with two different WinXP guests) and it is fixed immediately when downgrading to kernel 2.6.28.8 or an older kernel version. Works for me with modules from kvm-85. Ok, but as I write in my message, I'm using the KVM modules from the latest upstream kernel, not the kvm-85 modules. According to the KVM download page, http://www.linux-kvm.org/page/Downloads, any kernel above 2.6.25 should work with the latest KVM userspace. This has been true until now in my case, but it breaks with 2.6.29.1 and that's the reason why I'm posting this bug report. Best Regards Kenni Lund -- 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
Unable to boot guest on kernel 2.6.29.1 with kvm-84 or kvm-85
Hi When updating to kernel 2.6.29.1, I'm unable to boot my Windows XP Pro 32bit guest. The problem is consistent (actually on both of my laptops, with two different WinXP guests) and it is fixed immediately when downgrading to kernel 2.6.28.8 or an older kernel version. Scenario: I'm booting the guest with the command qemu-kvm -smp 2 -m 1024 -net nic -net user -daemonize -vnc :1 -hda /data/virtualization/winxp.img -boot c I connect with VNC and see the QEMU BIOS, followed by the Windows menu which lets me select if I want to boot Windows in safe mode or not. It counts down from 30, but when it get to 0 or once I hit the Start Windows Normally it freezes and nothing more happens. The following is written to dmesg when qemu-kvm is launched: kvm: 4609: cpu1 unhandled wrmsr: 0xc0010117 data 0 kvm: 4609: cpu0 unhandled wrmsr: 0xc0010117 data 0 Further information: KVM version: 84+85 (userspace only, kernel modules from stock kernel) I've tested -no-kvm-irqchip and -no-kvm-pit as the bugs-page describes, but it doesn't make a difference. Adding -no-kvm actually FIXES the issue and make Windows boot...so it doesn't seem to be QEMU related. # uname -a Linux T61 2.6.29-ARCH #1 SMP PREEMPT Fri Apr 17 12:46:01 UTC 2009 i686 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz GenuineIntel GNU/Linux # lsmod|grep kvm kvm_intel 39208 0 kvm 144944 1 kvm_intel Is this a known problem with this kernel version? If not, what can I do to help debugging it further? Best Regards Kenni Lund -- 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
Questions about relation between kernel version and KVM userspace version
Hi list I've been wondering about something for a while: How does the version of the kernel module and the version of the KVM userspace relate? Eg. if you run with a newer 2.6.27-2.6.28 kernel with the modules included, will you then benefit from using the modules from the latest KVM release together with the latest KVM userspace, or isn't it worth the effort? According to http://kvm.qumranet.com/kvmwiki/Downloads, it is required to use at least kernel 2.6.25 to run KVM userspace 76 or newer. Does this mean that no changes/bugfixes has been made to the KVM kernel module since 2.6.25? Or is it because all the major bugfixes are made in KVM userspace instead of the KVM kernel modules? And one last thing: When I compile the latest KVM modules from sourceforge, I'll be able to see the KVM module version in /var/log/messages when I load the module. But this isn't the case when I load the modules that comes with the kernel - how can I see check the KVM module version of the current kernel? modinfo etc. doesn't give out any information. Thank you in advance... Best Regards Kenni -- 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
