[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Fwd: In Use tracker for network and pci-passthrough devices: Laine response

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

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]