Re: [Xen-devel] [PATCH RFC 0/4] tools: Upstream blktap "2.5" as an external repo

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel