From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acspp-00047P-Dj for qemu-devel@nongnu.org; Mon, 07 Mar 2016 05:56:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acspl-00072V-DB for qemu-devel@nongnu.org; Mon, 07 Mar 2016 05:56:21 -0500 Received: from mx2.suse.de ([195.135.220.15]:36852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acspl-00072O-5e for qemu-devel@nongnu.org; Mon, 07 Mar 2016 05:56:17 -0500 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> From: Juergen Gross Message-ID: <56DD5E4F.7060906@suse.com> Date: Mon, 7 Mar 2016 11:56:15 +0100 MIME-Version: 1.0 In-Reply-To: <20160307105107.GA31271@citrix.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Wei Liu Cc: "qemu-devel@nongnu.org" , Paul Durrant , Stefano Stabellini , "aneesh.kumar@linux.vnet.ibm.com" , Anthony Perard , Xen-devel , "gkurz@linux.vnet.ibm.com" 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