On Fri, Mar 22, 2013 at 05:36:09PM +0800, Chunyan Liu wrote:
> Hi, List,
>
> As the mail I've sent a week before:
> https://www.redhat.com/archives/libvir-list/2013-March/msg00730.html
> I'm willing to push this work forward so that the passthrough APIs
> could be reused by qemu driver and libxl driver (which doesn't support
> pci passthrough yet and tries to add this function recently), or other
> drivers.
>
> But since this work affacts a lot, I'm not sure if I can control it in
> a correct way. I write a draft to describe what I'm considering how to
> do, as in the following and in attachment. Hope to get your review,
> comment and guidence to improve the work before start coding. Any
> feedback will be very appreciated!
>
> Thanks!
> Chunyan
>
> ------------------------
> DRAFT:
>
> Write separate module for hostdev passthrough
>
> 1. Purposes:
>
>    * Move hostdev passthrough APIs from qemu_hostdev.ch to separate module so
>      that they could be reused by other hypervisors too
>
>    * Maintain global in-use state of hostdevs
>
>
> 2. Module design (draft):
>
>    * New module name: hostdev_driver
>
>    * New module files: hostdev_driver.ch hostdev_conf.ch
>
>    * New Definitions:
>
>         ## [src/driver.h]
>
>         typedef struct _virHostdevDriver virHostdevDriver;
>
>         typedef virHostdevDriver *virHostdevDriverPtr;
>
>         struct _virHosedevDriver {
>             const char *name;
>             virDrvOpen                  open;
>             virDrvClose                 close;
>
>             virDrvPrepareHostdevs        prepareHostdevs;
>             virDrvPreparePciHostdevs        preparePciHostdevs;
>             virDrvprepareUsbHostdevs        prepareUsbHostdevs;
>             virDrvReattachHostdevs        reattachHostdevs;
>             virDrvReattachPciHostdevs        reattachPciHostdevs;
>             virDrvReattachUsbHostdevs       reattachUsbHostdevs;
>             virDrvGetActivePciHostdevList       getActivePciHostdevList;
>             virDrvGetActiveUsbHostdevList       getActiveUsbHostdevList;
>             virDrvGetDomainActivePciHostdevList
> getDomainActivePciHostdevList;
>             virDrvGetDomainActiveUsbHostdevList
> getDomainActiveUsbHostdevList;
>            };

This is real overkill - we only need to do the driver table
design for things which are public APIs with multiple pluggable
implementations.

For this scenario, we simply need one single set of internal APIs
that any of the stateful hypervisor drivers can directly call into.
Basically you just need to define some object to maintain the
state eg

    virHostdevManagerPtr

and a method to get the default shared instance of it

   virHostdevManagerPtr virHostdevManagerGetDefault();

and then the various APIs for interacting with it

     virHostdevManagerPrepareHostdevs(virHostdevManagerPtr mgr, ....);
     ...etc..

I'd just put this is all in a src/util/virhostdevmanager.{c,h}
file.

Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|