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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: qemu-devel-bounces+paul.durrant=citrix.com@xxxxxxxxxx
> [mailto:qemu-devel-bounces+paul.durrant=citrix.com@xxxxxxxxxx] On
> Behalf Of Wei Liu
> Sent: 12 February 2016 19:11
> To: qemu-devel@xxxxxxxxxx; Xen-devel
> Cc: Anthony Perard; gkurz@xxxxxxxxxxxxxxxxxx; Wei Liu;
> aneesh.kumar@xxxxxxxxxxxxxxxxxx; Stefano Stabellini
> Subject: [Qemu-devel] RFC: configuring QEMU virtfs for Xen PV(H) guests
> 
> # Background
> 
> To configure virtfs, there is two methods in QEMU command line:
> 
> 1. Use -fsdev and -device virtio-9p-pci,XXX directives
> 2. Use -virtfs directive
> 
> The second method is actually shorthand for the first method. It
> constructs fsdev and device options behind the scene. In the end,
> there will be a virtio-9p-pci device (transport for 9pfs) in QEMU. To
> make the discussion easier, I only use the first syntax.
> 
> Xen uses QEMU for two purposes. One is to use QEMU to emulate a PC
> machine (which is more or less the same as KVM), the other is to use
> QEMU to provide services (no emulation needed). The discussion is
> about the second usecase.
> 
> While Xen uses QEMU as a backend to provide service to PV(H) guests,
> it has its own idea of various objects. It is not totally compatible
> with QEMU's world view.
> 
> To avoid digging to deep into the code, here is how Xen arranges QEMU
> to work as PV backends (using nic as example):
> 
> 1. Toolstack arranges some xenstore entries.
> 2. Toolstack arranges command line options for QEMU:
>       -netdev XXX -device YYY
> 3. QEMU starts up in xen-attach mode, scans xenstore for relevant
>    entries, then traverse QEMU's nb_table (where information for all
>    nics is stored) for relevant entries and "steals" the device.
> 
> Now the question is how we to configure virtfs for Xen PV(H) guests?
> 
> # Option 1: Try to steal the device as before.
> 
> There doesn't seem to be a centralised reference point for
> virtio-9p-pci devices. So even if I want to steal it, I would need to
> traverse whole machine hierarchy. I would be happy if anybody knows a
> way to pick out specific devices -- in this case virtio-9p-pci. In
> this particular case:
> 
> 1. Toolstack arranges some xenstore entries.
> 2. Toolstack arranges command line options for QEMU:
>       -fsdev XXX -device virtio-9p-pci,XXX
> 3. QEMU starts up in xen-attach mode, scans xenstore for relevant
>    entries, traverses its object hierarchy for device and then
>    steals it.
> 
> Downside: The main difficulty is I don't know how to pick the right
> device. But maybe that's just me not knowing the right way of doing
> things.
> 
> # 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.
> 

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

  Paul

> # Option 3: Only use -fsdev
> 
> The third way of doing it would be to not use QEMU command line to
> create device at all. We only use -fsdev to create fsdev and in
> xen_init_pv we reply on information in xenstore to create 9pfs
> transport. In this case:
> 
> 1. Toolstack arranges some xenstore entries.
> 2. Toolstack arranges command line options for QEMU:
>       -fsdev XXX
> 3. QEMU starts up in xen-attach mode, scans xenstore for relevant
>    entries, creates 9pfs transport on the fly.
> 
> Downside: This seems to deviate from how we do things before
> (comparing with other device like nic and disk).
> 
> # Option 4
> 
> If you have other ideas, do let me know. :-)
> 
> Comments are welcome. I would like to know your opinions before
> actually writing code.
> 
> 
> Wei.


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