From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39266) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVJ0w-00068a-TJ for qemu-devel@nongnu.org; Mon, 15 Feb 2016 08:16:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVJ0r-0003vr-P0 for qemu-devel@nongnu.org; Mon, 15 Feb 2016 08:16:30 -0500 Received: from smtp.citrix.com ([66.165.176.89]:11123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVJ0r-0003ve-Kz for qemu-devel@nongnu.org; Mon, 15 Feb 2016 08:16:25 -0500 Date: Mon, 15 Feb 2016 13:16:21 +0000 From: Wei Liu Message-ID: <20160215131621.GL8818@citrix.com> References: <20160212191037.GF8818@citrix.com> <3fbbf2a606a14f708655037f5e4fb31e@AMSPEX02CL03.citrite.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <3fbbf2a606a14f708655037f5e4fb31e@AMSPEX02CL03.citrite.net> Subject: Re: [Qemu-devel] RFC: configuring QEMU virtfs for Xen PV(H) guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Durrant Cc: Wei Liu , "qemu-devel@nongnu.org" , Stefano Stabellini , "aneesh.kumar@linux.vnet.ibm.com" , Anthony Perard , Xen-devel , "gkurz@linux.vnet.ibm.com" 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