2013/4/17 Daniel P. Berrange <berrange(a)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.