[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: |
Paul Durrant |
Subject: |
Re: [Qemu-devel] RFC: configuring QEMU virtfs for Xen PV(H) guests |
Date: |
Mon, 15 Feb 2016 09:07:13 +0000 |
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Wei Liu
> Sent: 12 February 2016 19:11
> To: address@hidden; Xen-devel
> Cc: Anthony Perard; address@hidden; Wei Liu;
> address@hidden; 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.