Re: [Xen-devel] [Qemu-devel] RFC: configuring QEMU virtfs for Xen PV(H) guests

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> Sent: 15 February 2016 13:16
> To: Paul Durrant
> Cc: Wei Liu; qemu-devel@xxxxxxxxxx; Xen-devel; Anthony Perard;
> gkurz@xxxxxxxxxxxxxxxxxx; aneesh.kumar@xxxxxxxxxxxxxxxxxx; Stefano
> Stabellini
> Subject: Re: [Qemu-devel] RFC: configuring QEMU virtfs for Xen PV(H)
> guests
> 
> On Mon, Feb 15, 2016 at 09:07:13AM +0000, Paul Durrant wrote:
> > >
> [...]
> > > # Option 2: Invent a xen-9p device
> > >
> > > Another way of doing it is to expose a dummy xen-9p device, so that we
> > > can use -fsdev XXX -device xen-9p,YYY.  This simple device should be
> > > used to capture the parameters like mount_tag and fsdev_id, and then
> > > chained itself to a known location.  Later Xen transport can traverse
> > > this known location. This xen-9p device doesn't seem to fit well into
> > > the hierarchy. The best I can think of its parent should be
> > > TYPE_DEVICE.  In this case:
> > >
> > > 1. Toolstack arranges some xenstore entries.
> > > 2. Toolstack arranges command line options for QEMU:
> > >       -fsdev XXX -device xen-9p,XXX
> > > 3. QEMU starts up in xen-attach mode, scans xenstore for relevant
> > >    entries, then traverses the known location.
> > >
> > > Downside: Inventing a dummy device looks suboptimal to me.
> > >
> >
> 
> I wasn't talking about inventing a whole new hierarchy for XENBUS
> devices. I didn't talk about that because that's not strictly related to
> 9p project and maybe a project in its own right.  But I'm glad you
> notice this possibility.
> 
> > This sounds like a reasonable approach to me and surely it can be made
> > generic (i.e. not tied to virtfs specifically). All we need as a new
> > device type 'xenbus-device' or somesuch and a parameter to that device
> > which specifies the exact xenstore entry for that device and all other
> > configuration information is specified there e.g whether it's a vif,
> > vbd, 9p or whatever. The correct backend can then be kicked off
> > directly. No scanning required. No stealing required.  As for the
> > device type, would it not be best to have a proper XENBUS bus type?
> 
> Yes, that would be good. It's just not implemented yet.
> 
> > All the code which actually talks to xenstore could be collected there
> > and then you could have all XENBUS_DEVICEs using that common code via
> > the class hierarchy?
> >
> 
> I can have a look into this. We can probably start with 9p and gradually
> graft all other devices to XENBUS device hierarchy. I don't think all
> other PV devices are in dire need for this hierarchy at the moment.
> 

That may be true, but with the infrastructure in place in a common class (for 
things like manipulation of the xenbus state machine), I suspect the other 
backends could be easily be ported over with a substantial reduction in 
complexity and quantity of code.

  Paul

> Wei.
> 
> >   Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel