# 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.
# 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@lists.xen.org
http://lists.xen.org/xen-devel
