4:41 p.m.
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/c...
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
7:42 p.m.
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/c...
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
8:50 p.m.
Quoting Jaap Winius <jwinius(a)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
9:51 a.m.
Quoting Jaap Winius <jwinius(a)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
4590
days inactive
4602
days old
3 comments
2 participants
participants (2)
-
Jaap Winius -
Wen Congyang