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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.


> 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