From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH RFC 0/4] tools: Upstream blktap "2.5" as an
 external repo
Date: Thu, 26 Mar 2015 17:12:15 +0000
Message-ID: <55143DEF.9060709@citrix.com>
References: <1427373970-25399-1-git-send-email-george.dunlap@eu.citrix.com>
	<20150326154736.GC4790@humongous.uk.xensource.com>
	<55142F09.4020401@eu.citrix.com>
	<9F2C4E7DFB7839489C89757A66C5AD62A4BE57@AMSPEX01CL03.citrite.net>
	<55143C60.2000907@eu.citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <55143C60.2000907@eu.citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: George Dunlap <george.dunlap@eu.citrix.com>, Felipe Franciosi <felipe.franciosi@citrix.com>, George Dunlap <George.Dunlap@citrix.com>, Jonathan Ludlam <Jonathan.Ludlam@citrix.com>
Cc: Dave Scott <Dave.Scott@citrix.com>, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, Wen Congyang <wency@cn.fujitsu.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Ian Jackson <Ian.Jackson@citrix.com>, Yang Hongyang <yanghy@cn.fujitsu.com>
List-Id: xen-devel@lists.xenproject.org

On 26/03/15 17:05, George Dunlap wrote:
> On 03/26/2015 04:25 PM, Felipe Franciosi wrote:
>>> Another thing I'd like to explore (since this took all of about an afternoon to get
>>> working) is what it would take to switch to using
>>> blktap3 instead.  As I understand from my conversations with the XenServer
>>> team, they use a kernel module in XenServer when mounting an image in dom0
>>> for scalability reasons; but there's no reason XenProject need to do the same
>>> thing.
>> Today, to access virtual disks in dom0 we use the blktap2 kernel module that Jonathan Ludlam mentioned. This provides a block device (in /dev/xen/blktap-2/tapdev<minor>). In the (somewhat distant) past, we actually had blkfront in dom0.
> OK -- so the XenServer blktap2 kernel module is definitely being
> maintained.  That's good to know.
>
>> What is also needed to get blktap3 working is a gntdev supporting grant copy. I believe this is the order they are applied in 3.10:
>> https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-xen-install-xen-gntdev.h-and-xen-gntalloc.h.patch
>> https://github.com/xenserver/linux-3.x.pg/blob/master/master/xen-gntdev-grant-copy.patch
>> https://github.com/xenserver/linux-3.x.pg/blob/master/master/0002-xen-gntdev-mark-userspace-PTEs-as-special-on-x86-PV-.patch
>> https://github.com/xenserver/linux-3.x.pg/blob/master/master/0003-xen-gntdev-provide-a-set-of-pages-for-the-VMA.patch
>>
>> The _main_ difference between tapdisk2 and 3 is that tapdisk3 can connect directly to blkfront. It does all I/O via grant copies which has some implications in the way memory is handled in dom0.
> Right, I didn't realize blktap3 also required kernel changes.  Are those
> reasonably upstream-able, and is there any plan by the XenServer team to
> upstream them?

They are all in Linux 3.19 iirc.  These are not patches for blktap3 
specially; they are all patches fixing the use of userspace grant maps 
with /dev/xen/gnttab, which never functioned correctly in the past.

~Andrew