From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acssw-0005In-9k for qemu-devel@nongnu.org; Mon, 07 Mar 2016 05:59:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acsss-0007sv-3v for qemu-devel@nongnu.org; Mon, 07 Mar 2016 05:59:34 -0500 Received: from smtp.citrix.com ([66.165.176.89]:55797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acssr-0007sm-Vp for qemu-devel@nongnu.org; Mon, 07 Mar 2016 05:59:30 -0500 Date: Mon, 7 Mar 2016 10:59:27 +0000 From: Wei Liu Message-ID: <20160307105927.GC31271@citrix.com> References: <20160212191037.GF8818@citrix.com> <3fbbf2a606a14f708655037f5e4fb31e@AMSPEX02CL03.citrite.net> <20160215131621.GL8818@citrix.com> <56C1D391.101@suse.com> <20160215134409.GM8818@citrix.com> <56DD2C0A.5050509@suse.com> <20160307105107.GA31271@citrix.com> <56DD5E4F.7060906@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <56DD5E4F.7060906@suse.com> Subject: Re: [Qemu-devel] [Xen-devel] RFC: configuring QEMU virtfs for Xen PV(H) guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juergen Gross Cc: Wei Liu , "qemu-devel@nongnu.org" , Paul Durrant , Stefano Stabellini , "aneesh.kumar@linux.vnet.ibm.com" , Anthony Perard , Xen-devel , "gkurz@linux.vnet.ibm.com" 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 >