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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list