Re: [PATCH 8/8] raisin: RFC Add blktap2 as an external tree

[George Dunlap <george.dunlap@eu.citrix.com>]

On 04/21/2015 10:25 AM, Ian Campbell wrote:
> On Mon, 2015-04-20 at 18:05 +0100, Stefano Stabellini wrote:
>>>> I think we need to disable the build on architectures other than x86,
>>>> see grub for example
> 
> Eventually we might want to build our own grub on ARM in order to pick
> up Fu Wei's multiboot for arm64 patches, until they enter distros?
> 
> Or maybe Raisin on UEFI should be calling efibootmgr to register Xen
> directly with the BIOS, and creating a xen.cfg in /boot, i.e. the way it
> currently works even on x86.
> 
>>> Do we?  There's no reason a blktap2 kernel module couldn't be built on
>>> ARM, is there?
>>
>> Maybe not, but I am pretty sure that it doesn't work at the moment. I
>> don't think that the userspace stuff even compiles on ARM.
>> Eventually we might have blktap on ARM, but I don't want to enable
>> stuff in Raisin that we know it does not work.
> 
> Especially if it is already to a greater or lesser extent deprecated (in
> favour of eventual blktap3) even on x86.

So from my discussions w/ the XenServer guys, it seems that:

1. The "master" branch of the blktap.git repo contains support for
*both* blktap3 and blktap2.5 (with a kernel module)

2. XenServer uses blktap3 for guest access, but still use the blktap2.5
w/ kernel module for dom0 access to guest disks, to avoid the
possibility of hitting a scalability limit due to grant references.

So from raisin's perspective, the only difference between blktap2.5 and
blktap3 is using the "master" branch rather than the "blktap2" branch of
the repo.

Whether we maintain support for blktap2.5 in libxl is a matter for the
Xen maintainers; but if xapi is ever going to start using libxl, it will
certainly need to be able to do so.

(Dave / David, please correct me if I'm wrong.)

That said, there's no harm in disabling it on ARM to begin with, and
enabling it once blktap3 works.

 -George