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

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

> On 21 Apr 2015, at 11:42, Stefano Stabellini 
> <Stefano.Stabellini@xxxxxxxxxxxxx> wrote:
> 
> On Tue, 21 Apr 2015, George Dunlap wrote:
>> 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. :-)
> 
> No, that is not right. The reason I would like to disable blktap2 for
> ARM is that the userspace binaries and libraries won't compile on ARM at
> the moment. At least that was the case the last time I tried it. If you
> prove me wrong, I would be happy to have blktap2 on ARM too.

FYI Iâve been sporadically building the blktap userspace on ARM and it seems to 
work, although last time I had to fix some format strings which assumed a 
64-bit architecture. I think that patch got merged. I think my last build was 
in January.

The Mirage xen-arm-builder images currently contain a patched kernel with the 
blktap driver added as a patch, and a build of xapi + libxl + the blktap 
userspace tools. Itâs only been lightly tested though :-)

Cheers,
Dave

> 
> 
>> 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. :-)
> 
> Right, I am not worried about the build time.

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