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

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

[Wei Liu]

# 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.

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

[Paul Durrant]

> -----Original Message-----
> From: qemu-devel-bounces+paul.durrant=citrix.com@nongnu.org
> [mailto:qemu-devel-bounces+paul.durrant=citrix.com@nongnu.org] On
> Behalf Of Wei Liu
> Sent: 12 February 2016 19:11
> To: qemu-devel@nongnu.org; Xen-devel
> Cc: Anthony Perard; gkurz@linux.vnet.ibm.com; Wei Liu;
> aneesh.kumar@linux.vnet.ibm.com; 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.

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

[Wei Liu]

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

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

[Paul Durrant]

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: 15 February 2016 13:16
> To: Paul Durrant
> Cc: Wei Liu; qemu-devel@nongnu.org; Xen-devel; Anthony Perard;
> gkurz@linux.vnet.ibm.com; aneesh.kumar@linux.vnet.ibm.com; Stefano
> Stabellini
> Subject: Re: [Qemu-devel] RFC: configuring QEMU virtfs for Xen PV(H)
> guests
> 
> 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.
> 

That may be true, but with the infrastructure in place in a common class (for things like manipulation of the xenbus state machine), I suspect the other backends could be easily be ported over with a substantial reduction in complexity and quantity of code.

  Paul

> Wei.
> 
> >   Paul

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

[Juergen Gross]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On 15/02/16 14:16, Wei Liu wrote:
> 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.

Sorry, didn't notice this thread before.

For Xen pvUSB backend in qemu I need a Xen system device acting as
parent for being able to attach/detach virtual USB busses.

I haven't had time to update my patches for some time, but the patch
for this system device is rather easy. It could be used as a parent
of the xen-9p devices, too.

I've attached the patch for reference.


Juergen

[-- Attachment #2: 0001-xen-introduce-dummy-system-device.patch --]
[-- Type: text/x-patch, Size: 3131 bytes --]

>From 1bc23acf54e60c666b1ec8e3f59c7e5550423e6f Mon Sep 17 00:00:00 2001
From: Juergen Gross <jgross@suse.com>
Date: Thu, 3 Sep 2015 11:54:50 +0200
Subject: [Patch V1 1/3] xen: introduce dummy system device

Introduce a new dummy system device serving as parent for virtual
buses. This will enable new pv backends to introduce virtual buses
which are removable again opposed to system buses which are meant
to stay once added.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 hw/xenpv/xen_machine_pv.c    | 39 +++++++++++++++++++++++++++++++++++++++
 include/hw/xen/xen_backend.h |  1 +
 2 files changed, 40 insertions(+)

diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 2e545d2..57bc071 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -24,10 +24,15 @@
 
 #include "hw/hw.h"
 #include "hw/boards.h"
+#include "hw/sysbus.h"
 #include "hw/xen/xen_backend.h"
 #include "xen_domainbuild.h"
 #include "sysemu/block-backend.h"
 
+#define TYPE_XENSYSDEV "xensysdev"
+
+DeviceState *xen_sysdev;
+
 static void xen_init_pv(MachineState *machine)
 {
     const char *kernel_filename = machine->kernel_filename;
@@ -59,6 +64,9 @@ static void xen_init_pv(MachineState *machine)
         break;
     }
 
+    xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
+    qdev_init_nofail(xen_sysdev);
+
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("vfb", &xen_framebuffer_ops);
@@ -93,6 +101,31 @@ static void xen_init_pv(MachineState *machine)
     xen_init_display(xen_domid);
 }
 
+static int xen_sysdev_init(SysBusDevice *dev)
+{
+    return 0;
+}
+
+static Property xen_sysdev_properties[] = {
+    {/* end of property list */},
+};
+
+static void xen_sysdev_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
+
+    k->init = xen_sysdev_init;
+    dc->props = xen_sysdev_properties;
+}
+
+static const TypeInfo xensysdev_info = {
+    .name          = TYPE_XENSYSDEV,
+    .parent        = TYPE_SYS_BUS_DEVICE,
+    .instance_size = sizeof(SysBusDevice),
+    .class_init    = xen_sysdev_class_init,
+};
+
 static QEMUMachine xenpv_machine = {
     .name = "xenpv",
     .desc = "Xen Para-virtualized PC",
@@ -101,9 +134,15 @@ static QEMUMachine xenpv_machine = {
     .default_machine_opts = "accel=xen",
 };
 
+static void xenpv_register_types(void)
+{
+    type_register_static(&xensysdev_info);
+}
+
 static void xenpv_machine_init(void)
 {
     qemu_register_machine(&xenpv_machine);
 }
 
+type_init(xenpv_register_types)
 machine_init(xenpv_machine_init);
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 3b4125e..911ba6d 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -59,6 +59,7 @@ struct XenDevice {
 extern XenXC xen_xc;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
+extern DeviceState *xen_sysdev;
 
 /* xenstore helper functions */
 int xenstore_write_str(const char *base, const char *node, const char *val);
-- 
2.1.4

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

[Wei Liu]

On Mon, Feb 15, 2016 at 02:33:05PM +0100, Juergen Gross wrote:
> On 15/02/16 14:16, Wei Liu wrote:
> > 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.
> 
> Sorry, didn't notice this thread before.
> 

No need to be sorry. I posted this last Friday night. I wouldn't expect
many replies on Monady.

> For Xen pvUSB backend in qemu I need a Xen system device acting as
> parent for being able to attach/detach virtual USB busses.
> 
> I haven't had time to update my patches for some time, but the patch
> for this system device is rather easy. It could be used as a parent
> of the xen-9p devices, too.
> 
> I've attached the patch for reference.
> 

Thanks. I will have a look at your patch.

Wei.

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

[Stefano Stabellini]

On Fri, 12 Feb 2016, Wei Liu wrote:
> # 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).

I think this is best and actually it is like the other PV devices in
QEMU: xen_nic is not used at all and xen_disk is configured without
command line options, like you are suggesting here.

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

[Juergen Gross]

Hi Wei,

On 15/02/16 14:44, Wei Liu wrote:
> On Mon, Feb 15, 2016 at 02:33:05PM +0100, Juergen Gross wrote:
>> On 15/02/16 14:16, Wei Liu wrote:
>>> 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.
>>
>> Sorry, didn't notice this thread before.
>>
> 
> No need to be sorry. I posted this last Friday night. I wouldn't expect
> many replies on Monady.
> 
>> For Xen pvUSB backend in qemu I need a Xen system device acting as
>> parent for being able to attach/detach virtual USB busses.
>>
>> I haven't had time to update my patches for some time, but the patch
>> for this system device is rather easy. It could be used as a parent
>> of the xen-9p devices, too.
>>
>> I've attached the patch for reference.
>>
> 
> Thanks. I will have a look at your patch.

Did you have some time to look at the patch? I'm asking because I
finally found some time to start working on V2 of my qemu based pvUSB
backend. Stefano asked me to hide the system device in my backend and
I want to avoid that in case you are needing it, too.

Juergen

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

[Wei Liu]

On Mon, Mar 07, 2016 at 08:21:46AM +0100, Juergen Gross wrote:
> Hi Wei,
> 
> On 15/02/16 14:44, Wei Liu wrote:
> > On Mon, Feb 15, 2016 at 02:33:05PM +0100, Juergen Gross wrote:
> >> On 15/02/16 14:16, Wei Liu wrote:
> >>> 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.
> >>
> >> Sorry, didn't notice this thread before.
> >>
> > 
> > No need to be sorry. I posted this last Friday night. I wouldn't expect
> > many replies on Monady.
> > 
> >> For Xen pvUSB backend in qemu I need a Xen system device acting as
> >> parent for being able to attach/detach virtual USB busses.
> >>
> >> I haven't had time to update my patches for some time, but the patch
> >> for this system device is rather easy. It could be used as a parent
> >> of the xen-9p devices, too.
> >>
> >> I've attached the patch for reference.
> >>
> > 
> > Thanks. I will have a look at your patch.
> 
> Did you have some time to look at the patch? I'm asking because I
> finally found some time to start working on V2 of my qemu based pvUSB
> backend. Stefano asked me to hide the system device in my backend and
> I want to avoid that in case you are needing it, too.
> 

Yes. I need this device. I'm not sure what "hiding this device in
backend" means though.

Wei.

> Juergen

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

[Juergen Gross]

On 07/03/16 11:51, Wei Liu wrote:
> On Mon, Mar 07, 2016 at 08:21:46AM +0100, Juergen Gross wrote:
>> Hi Wei,
>>
>> On 15/02/16 14:44, Wei Liu wrote:
>>> On Mon, Feb 15, 2016 at 02:33:05PM +0100, Juergen Gross wrote:
>>>> On 15/02/16 14:16, Wei Liu wrote:
>>>>> 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.
>>>>
>>>> Sorry, didn't notice this thread before.
>>>>
>>>
>>> No need to be sorry. I posted this last Friday night. I wouldn't expect
>>> many replies on Monady.
>>>
>>>> For Xen pvUSB backend in qemu I need a Xen system device acting as
>>>> parent for being able to attach/detach virtual USB busses.
>>>>
>>>> I haven't had time to update my patches for some time, but the patch
>>>> for this system device is rather easy. It could be used as a parent
>>>> of the xen-9p devices, too.
>>>>
>>>> I've attached the patch for reference.
>>>>
>>>
>>> Thanks. I will have a look at your patch.
>>
>> Did you have some time to look at the patch? I'm asking because I
>> finally found some time to start working on V2 of my qemu based pvUSB
>> backend. Stefano asked me to hide the system device in my backend and
>> I want to avoid that in case you are needing it, too.
>>
> 
> Yes. I need this device. I'm not sure what "hiding this device in
> backend" means though.

Stefano wanted it to be pvusb backend private: instead of adding it to
hw/xenpv/xen_machine_pv.c he wanted me to add it to hw/usb/xen-usb.c
where it would be usable by the pvUSB backend only.

With you needing that device I can leave the patch more or less
unmodified (some rebasing to the actual qemu version is needed).

Thanks for looking into the patch,

Juergen

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

[Wei Liu]

On Mon, Mar 07, 2016 at 11:56:15AM +0100, Juergen Gross wrote:
> On 07/03/16 11:51, Wei Liu wrote:
> > On Mon, Mar 07, 2016 at 08:21:46AM +0100, Juergen Gross wrote:
> >> Hi Wei,
> >>
> >> On 15/02/16 14:44, Wei Liu wrote:
> >>> On Mon, Feb 15, 2016 at 02:33:05PM +0100, Juergen Gross wrote:
> >>>> On 15/02/16 14:16, Wei Liu wrote:
> >>>>> 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.
> >>>>
> >>>> Sorry, didn't notice this thread before.
> >>>>
> >>>
> >>> No need to be sorry. I posted this last Friday night. I wouldn't expect
> >>> many replies on Monady.
> >>>
> >>>> For Xen pvUSB backend in qemu I need a Xen system device acting as
> >>>> parent for being able to attach/detach virtual USB busses.
> >>>>
> >>>> I haven't had time to update my patches for some time, but the patch
> >>>> for this system device is rather easy. It could be used as a parent
> >>>> of the xen-9p devices, too.
> >>>>
> >>>> I've attached the patch for reference.
> >>>>
> >>>
> >>> Thanks. I will have a look at your patch.
> >>
> >> Did you have some time to look at the patch? I'm asking because I
> >> finally found some time to start working on V2 of my qemu based pvUSB
> >> backend. Stefano asked me to hide the system device in my backend and
> >> I want to avoid that in case you are needing it, too.
> >>
> > 
> > Yes. I need this device. I'm not sure what "hiding this device in
> > backend" means though.
> 
> Stefano wanted it to be pvusb backend private: instead of adding it to
> hw/xenpv/xen_machine_pv.c he wanted me to add it to hw/usb/xen-usb.c
> where it would be usable by the pvUSB backend only.
> 
> With you needing that device I can leave the patch more or less
> unmodified (some rebasing to the actual qemu version is needed).
> 

Yes, please make it available to other PV backends. Someone might want
to graft every device we have to that hierarchy some day later. ;-)

> Thanks for looking into the patch,
> 

Thanks for posting this patch and sorry for the long delay.

Wei.

> Juergen
>