[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