From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 4/6] libxl: Use the block-tap script for LIBXL_DISK_BACKEND_TAP Date: Tue, 7 Jul 2015 15:20:08 +0100 Message-ID: <1436278808.25646.211.camel@citrix.com> References: <1436179903-449-1-git-send-email-george.dunlap@eu.citrix.com> <1436179903-449-5-git-send-email-george.dunlap@eu.citrix.com> <20150707122924.GX1134@zion.uk.xensource.com> <559BD6F4.2010707@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559BD6F4.2010707@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Wei Liu , Dave Scott , Wen Congyang , Felipe Franciosi , Jonathan Ludlam , xen-devel@lists.xen.org, Ian Jackson , Yang Hongyang List-Id: xen-devel@lists.xenproject.org On Tue, 2015-07-07 at 14:41 +0100, George Dunlap wrote: > On 07/07/2015 01:29 PM, Wei Liu wrote: > > On Mon, Jul 06, 2015 at 11:51:41AM +0100, George Dunlap wrote: > >> The block-tap script can now do everything needed for libxl; no need > >> to link against the blktap library. > >> > >> To do this: > >> > >> * Set disk->script to "block-tap" and dev to "format:pdev_path" in > >> device_disk_add for LIBXL_DISK_BACKEND_TAP > >> > >> * Remove libxl_blktap2.o and libxl_noblktap2.o and all code depending > >> on them > >> > >> Signed-off-by: George Dunlap > >> --- > >> CC: Ian Campbell > >> CC: Ian Jackson > >> CC: Wei Liu > >> CC: Dave Scott > >> CC: Jonathan Ludlam > >> CC: Wen Congyang > >> CC: Yang Hongyang > >> CC: Felipe Franciosi > >> > >> Note: This is broken for HVM domains at the moment because all block > >> scripts are broken for HVM domains. That is a bug which should be a > >> blocker for the 4.6 release. As such, I think there is justification > > > > This bug is partially fixed by this particular patch. I think making > > things partially work is better than having it not work at all. > > > >> for checking in this "feature" (enabling use of a 'system' blktap) > >> with the assumption that the FIXME will go away before the release. > >> > > > > I have the impression that to make QEMU work with block script (the > > FIXME) would require us to devise a way to get back the path of block > > device node. Am I right? How much work do you envisage is needed to make > > that FIXME go away? > > For block scripts where dom0 is the backend, I *think* we should in > theory be able change block-common to store a pathname to the device > node in xenstore and hand it to qemu. Alternately, we could fish the > existing major:minor numbers out of xenstore and make our own node to > pass to qemu. > > > On the flip side we're not making anything worse than before so we can > > probably get by by writing that down in known issues section of release > > note. > > We do technically cause a regression at the moment. Before this patch, > someone who has access to the blktap kernel module, and is using the > in-tree blktap, will be able to use a blktap backend with HVM guests. > Once this patch is accepted, blktap will work for PV guests, but not for > HVM guests -- at least until we fix the bug with local block scripts. Unfortunately that does sound like something which needs to be fixed before we accept this patch, doesn't it?