On 06/28/2012 05:21 AM, Shradha Shah wrote:
In the meantime, I think the right way to do this is by integrating with the code in the qemu driver that keeps track of which PCI devices are in use. This already happens at the very basic level of "if the device allocated by the network driver is in use, the attempt to assign the device will fail"; instead, the network driver should be able to ask qemu if the device it wants to allocate to the guest is already in use (and reserve it, in one atomic operation).
Of course, once the network driver has reserved the device from qemu's PCI passthrough code, it would return that device to the qemu driver code that wants to attach the interface, and it would fail because it would be told the device is already in use (well, yeah! *We* just marked it as in-use!). To make that work, I guess some sort of cookie/handle/pointer would need to be passed from qemu's pci passthrough code back to the network driver, and the network driver would return it back to qemu's network interface attach code, which would then use that special cookie/handle/pointer to attach the device (saying "yeah, I know it's already in use, and here's my pass-card").
Wouldn't this approach require network driver to call functions from the qemu driver? I think this is not good for the hierarchical structure we are trying to maintain.
Agreed, we need to move device tracking out of qemu and into common reusable code.
(Talking about this makes me think that the code that keeps track of PCI device allocation shouldn't really be a part of qemu, but should be a separate module, so that the network driver can still function properly even if the qemu driver isn't loaded.)
Would this mean moving code to a new driver called device_driver.c or devicetracker_driver.c (which consumes device_conf.ch) and is called by network, domain and qemu drivers?
Maybe even name it src/conf/nodedev_conf.[ch], since it deals with handling of node devices. But yes, the idea of a common file in src/conf that can then be shared between network and qemu drivers makes sense. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org