Created attachment 401626[details]
Cleaner Dmesg output
Ok, this is a slightly cleaner version of the dmesg output from my system.
I attempted to attach the firewire controller on my laptop to the virtual machine and I received the same error from the virtual machine manager as before.

I had to get vt-d to work so I did the following:
- switched to libvirt git from about two weeks ago
- run qemu-kvm as root
- added a patch to disable dropping the privileges before forking qemu-kvm (see my post to libvir-list@redhat.com)
- switched selinux to permissive mode
It's running now. I don't know which of these steps are still neccessary with the current updates or updates-testing. I probably will install a fresh F13 on a spare drive and be able to test it in a few days. Will report back then.

Gerd, I was only able to get PCI device assignment working by following those steps as well. All other times gave me the error:
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Libvirt now has a config option for to change the capabilities dropping behavior, so rebuilding the package isn't required.. I've outlined the work around steps here:
https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#PCI_device_assignment
There has been some upstream qemu + libvirt work that works around the process capability issues: libvirt opens the PCI device FD and passes it to qemu. However, those patches likely won't be backported to F12 or F13, so I think this will only be properly fixed in F14 and beyond. Reassigning to rawhide.

I'm seeing the same on Centos 6.3. This is the output from libvirt log,
get_real_device: read failed, errno = 9
get_real_device: /sys/bus/pci/devices/0000:02:00.4/resource: Permission denied
qemu-kvm: -device pci-assign,host=02:00.4,id=hostdev0,configfd=25,bus=pci.0,addr=0x4: pci-assign: Error: Couldn't get real device (hostdev0)!
qemu-kvm: -device pci-assign,host=02:00.4,id=hostdev0,configfd=25,bus=pci.0,addr=0x4: Device 'pci-assign' could not be initialized
When I manually launch the VM, it looks like the error will not show up if the "configfg=" is not specify.

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Whatever was the problem that required running as root and dropping caps when this bug was opened in 2010, it is no longer the case with F18.
(I know that the problem was fixed at one time, as it works properly in RHEL6.3/RHEL6.4, which is based on newer sources than the Fedora 12 this was reported against).
I've spent the last couple week diagnosing the current problem and writing a set of patches to overcome it. The problem now is caused by a *new* capability bit called CAP_COMPROMISE_KERNEL; if this capability isn't set in the qemu process, qemu will be unable to do setup a "pci-assign" device. CAP_COMPROMISE_KERNEL wasn't present in Fedora 17, but is in Fedora 18.
When I patch libvirt to properly set CAP_COMPROMISE_KERNEL in the qemu-kvm process, I can once again create pci passthrough devices without setting clear_emulator_capabilities=0 and without forcing qemu to run as root.
Since it's a separate issue though, I've filed a separate BZ: Bug 908888.

Note

You need to
log in
before you can comment on or make changes to this bug.