[libvirt] doc: write separate module for hostdev passthrough and in-use tracking

Chunyan Liu cyliu at suse.com
Thu Apr 18 08:56:02 UTC 2013


2013/4/17 Daniel P. Berrange <berrange at redhat.com>

> 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.
>

Got it. I'm writing it in the way you pointed, as a shared module instead
of a driver, as Osier has pointed out too. Thanks for your suggestion about
detail, I'll change code to follow that.


> 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:|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130418/06873b02/attachment-0001.htm>


More information about the libvir-list mailing list