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-Virtualization-PCI_passthrough.html#sect-Virtualization-PCI_passthrough-AI_device_to_a_host
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 = 2IIRC, 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-Virtualization-PCI_passthrough.html#sect-Virtualization-PCI_passthrough-AI_device_to_a_host > > > 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 at redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users >
Quoting Jaap Winius <jwinius at 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 = 2It 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