qemu-devel
[Top][All Lists]
Advanced

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

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


From: Wei Liu
Subject: Re: [Qemu-devel] RFC: configuring QEMU virtfs for Xen PV(H) guests
Date: Mon, 15 Feb 2016 13:16:21 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

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.

Wei.

>   Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]