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

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

> On 21 Apr 2015, at 12:01, Dave Scott <Dave.Scott@xxxxxxxxxx> wrote:
> 
>> 
>> 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 :-)

Quick followup, Iâve been building the tools with this patch:

https://github.com/xenserver/buildroot/blob/master/SOURCES/blktap-gntcpy.patch

This allows the build without the grant copy support.

> 
> 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