[libvirt-users] PCI passthrough error
Hi folks, Has anyone encountered the following PCI passthrough error? error: internal error Process exited while reading console \ log output: char device redirected to /dev/pts/1 assigned_dev_pci_read: pread failed, ret = 0 errno = 2 It's produced after I've detached the PCI device from the base OS and have tried to start up the guest domain. To get to this point, I mostly followed these instructions: http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/chap... The distro I'm using is Debian squeeze, which by default comes with libvirt 0.8.3 and qemu-kvm 0.12.5, although to avoid a different PCI passthrough error, I used Debian backports for squeeze to upgrade them to libvirt 0.9.8 and qemu-kvm 1.0. The motherboard involved has VT-d support, which I've enabled with the "intel_iommu=on" kernel option (dmesg shows "Intel-IOMMU: enabled"). I did not bother with setsebool because SELinux is disabled. According to lspci, the device I want to pass through to the guest domain, a USB controller, has bus/slot/function 00:1a.0, so I added the following stanza to the <devices> section of my guest domain: <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x00' slot='0x1a' function='0x0'/> </source> </hostdev> Actually, every time I save this configuration, libvirt changes it to: <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x00' slot='0x1a' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev> Huh, slot 5? I don't have any PCI devices that use slot 5. Well, at least the system doesn't complain, but I worry that this might be a symptom of something more serious. Anyway, I'd be very grateful if anyone has any tips on how I might avoid the aforementioned error and get PCI passthrough to to work. Thanks, Jaap
At 03/30/2012 05:41 AM, Jaap Winius Wrote:
Hi folks,
Has anyone encountered the following PCI passthrough error?
error: internal error Process exited while reading console \ log output: char device redirected to /dev/pts/1 assigned_dev_pci_read: pread failed, ret = 0 errno = 2
IIRC, the errno is wrong. ret 0 means that there is no more data in pci config space. the qemu process's user/group is qemu, and it can only read first 64/128bytes of the config space. When you use PCI passthrough, qemu will read PCI device's capabilities. All the capabilities's offset > 64/128 bits. Thanks Wen Congyang
It's produced after I've detached the PCI device from the base OS and have tried to start up the guest domain.
To get to this point, I mostly followed these instructions:
http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/chap...
The distro I'm using is Debian squeeze, which by default comes with libvirt 0.8.3 and qemu-kvm 0.12.5, although to avoid a different PCI passthrough error, I used Debian backports for squeeze to upgrade them to libvirt 0.9.8 and qemu-kvm 1.0.
The motherboard involved has VT-d support, which I've enabled with the "intel_iommu=on" kernel option (dmesg shows "Intel-IOMMU: enabled"). I did not bother with setsebool because SELinux is disabled.
According to lspci, the device I want to pass through to the guest domain, a USB controller, has bus/slot/function 00:1a.0, so I added the following stanza to the <devices> section of my guest domain:
<hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x00' slot='0x1a' function='0x0'/> </source> </hostdev>
Actually, every time I save this configuration, libvirt changes it to:
<hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x00' slot='0x1a' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev>
Huh, slot 5? I don't have any PCI devices that use slot 5. Well, at least the system doesn't complain, but I worry that this might be a symptom of something more serious.
Anyway, I'd be very grateful if anyone has any tips on how I might avoid the aforementioned error and get PCI passthrough to to work.
Thanks,
Jaap
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Quoting Jaap Winius <jwinius@umrk.nl>:
error: internal error Process exited while reading console \ log output: char device redirected to /dev/pts/1 assigned_dev_pci_read: pread failed, ret = 0 errno = 2
It turns out this is a KVM bug related to the Linux 2.6.32-5-amd64 kernel I was using with Debian squeeze. I fixed this by using Debian backports again to upgrade to the 3.2.0-0.bpo.2-amd64 kernel. Unfortunately, now when I try to get PCI passthrough to work I get this: error: Unable to read from monitor: Connection reset by peer Actually, when I checked to see if it would still work without the PCI passthrough stuff I seemed to get no errors, but it wouldn't start either. Then I found this kvm error in the guest's log: memory_region_add_subregion_common: Assertion `!subregion->parent' failed. Luckily, I found I could fix this by changing the machine type from pc-0.12 to pc-1.0 (I changed that with "virsh edit ..."). However, I still get the "Unable to read from monitor" error if I activate PCI passthrough, and I found some more in the guest's log too: char device redirected to /dev/pts/1 PCI region 0 at address 0xfb207000 has size 0x400, which is not a multiple of 4K. You might experience some performance hit due to that. No IOMMU found. Unable to assign device "hostdev0" kvm: -device pci-assign,host=00:1a.0,id=hostdev0,configfd=20,bus=pci.0,addr=0x5: Device 'pci-assign' could not be initialized 2012-03-30 00:49:58.209+0000: shutting down No IOMMU?? But, this new 3.2.0-0.bpo.2-amd64 kernel says "Intel-IOMMU: enabled" (that's from dmesg) when the system boots up, so what am I missing here? Well, whaddaya know. I did some more research on the chipset and found it to be an Intel BD82H61 PCH... http://ark.intel.com/products/52806/Intel-BD82H61-PCH ... which apparently does not support VT-d (have an IOMMU) after all. Doh! The BIOS does include a virtualization option, but I guess it's not about VT-d. I think what would have saved me a lot of time here (besides a better brain) is a simple way to test for the presence of an IOMMU, but I don't know of one. Anyway I guess now it's USB passthrough or bust. Or get a board with an IOMMU. Cheers, Jaap
Quoting Jaap Winius <jwinius@umrk.nl>:
... Anyway I guess now it's USB passthrough or bust. Or get a board with an IOMMU.
In case anyone is ever interested, I did eventually manage to solve this problem with a wrapper script, although not exactly the way David Wragg explains in his blog. With Debian squeeze, the problem is that when using virt-manager to configure USB passthrough, it allows you to select a USB device based on its vendorID and productID combination, which happens to be exactly what I need. However, when passing the selected device on to the virtual machine, the kvm command it generates is only for the bus/device combination that the selected device is currently using. That, combined with the lack of any hot-plug support is what was preventing me from getting my system to work. The solution for me was simply to bypass any methods using virt-manager or the virsh editor to define the devices for USB passthrough. Then, instead of using the wrapper script to modify any devices already defined, I use it to add all of the devices I need. It looks like this: #!/bin/sh exec /usr/bin/kvm `echo $* | sed 's/-vga std/-vga std -usbdevice host:auto:*.*:0c93:1772 -usbdevice host:auto:*.*:0c93:1771/'` Incidentally, this script has to have the same name as the executable, which on Debian squeeze is /usr/bin/kvm. So, I called this script /usr/local/bin/kvm, and not /usr/local/bin/qemu-kvm, like in Wragg's blog. Anyway, the above script allows me to start up the virtual machine with only one (or none) of the devices attached. Then the theory is that the Windows device driver loads some firmware into the device, which causes it to change its product ID from 1772 to 1771, as well as its device number. Crucially, my wrapper script doesn't care about this device number change and the new device is also passed through to the virtual machine. As far as I can tell, the Windows software continues to work as expected. Cheers, Jaap
participants (2)
-
Jaap Winius -
Wen Congyang