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

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

On 04/21/2015 11:09 AM, Stefano Stabellini wrote:
> On Tue, 21 Apr 2015, George Dunlap wrote:
>> 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.
> 
> That is not entirely true: compiling and installing a kernel module is
> quite different from userspace stuff, at least in terms of dependencies
> and installation paths.

The blktap.git repo doesn't compile a kernel module; it's only building
userspace binaries and libraries.  Libxl already knows how to detect the
presence or absence of the kernel module and behave accordingly.

>> 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.
> 
> Yes, I would the code in Raisin to actually work :-)

The code should work just fine.  When run on an ARM system without a
blktap2 kernel module, libxl should detect that blktap2 is not available
and not use it.  If someone builds their own ARM kernel with blktap2
enabled, it will use it.

The only reason to disable this on ARM at the minute is because you
*believe* that nobody will ever want to build the blktap2 kernel module
on ARM, and so you want to avoid the build overhead and space overhead
of compiling and using dead code.  If that's your goal, you might get
more mileage out of disabling stuff like xenmon or the paging code. :-)

There's already an ARM Server SIG for CentOS; once that gets completed,
Xen4CentOS project will probably also do an ARM server port, at which
point it will almost certainly attempt to port over the blktap2 kernel
modules.

Enabling blktap.git on ARM by default means a bit of extra compilation
time and code in the resulting binary (though not much at all).
Disabling it on ARM means that we'll have to enable it again once either
1) we get blktap3 working, or 2) someone shows an interest in using
blktap2 on ARM.

Both costs are so low as to make it a bike-shed issue in my mind.  I'd
paint the bike shed "Enable it by arm on default", but repainting the
shed when the time comes will be easy, so I don't care that much.  I
just want to make it clear that it *is* a bike-shed issue. :-)

 -George