Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap driver

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-05-16 at 10:51 +0100, Jan Beulich wrote:
> >>> On 16.05.12 at 11:16, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Wed, 2012-05-16 at 09:58 +0100, Jan Beulich wrote:
> >> >>> On 16.05.12 at 10:21, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >> > On Tue, 2012-05-15 at 17:21 +0100, George Dunlap wrote:
> >> >> On 15/05/12 17:16, Jan Beulich wrote:
> >> >> >>>> On 15.05.12 at 17:49, George Dunlap<george.dunlap@xxxxxxxxxxxxx>  
> >> >> >>>> wrote:
> >> >> >> Older kernels, such as those found in Debian Squeeze:
> >> >> >> * Have bugs in handling of AIO into foreign pages
> >> >> >> * Have blktap modules, which will cause qemu not to use AIO, but
> >> >> >> which are not loaded on boot.
> >> >> >>
> >> >> >> Attempt to load blktap in xencommons, to make sure modern qemu's 
> >> >> >> which
> >> >> >> use AIO will work properly on those kernels.
> >> >> >>
> >> >> >> Signed-off-by: George Dunlap<george.dunlap@xxxxxxxxxxxxx>
> >> >> >>
> >> >> >> diff -r 99244350516a -r db614e92faf7 
> >> >> >> tools/hotplug/Linux/init.d/xencommons
> >> >> >> --- a/tools/hotplug/Linux/init.d/xencommons  Tue May 15 16:48:49 
> >> >> >> 2012 +0100
> >> >> >> +++ b/tools/hotplug/Linux/init.d/xencommons  Tue May 15 16:49:32 
> >> >> >> 2012 +0100
> >> >> >> @@ -59,6 +59,7 @@ do_start () {
> >> >> >>      modprobe evtchn 2>/dev/null
> >> >> >>      modprobe gntdev 2>/dev/null
> >> >> >>      modprobe xen-acpi-processor 2>/dev/null
> >> >> >> +    modprobe blktap 2>/dev/null
> >> >> > Can we stop manually loading all kinds of drivers here? I was
> >> >> > glad this went away with the switch to xencommons, and
> >> >> > now this is coming back. Drivers definitely needed in all cases
> >> >> > are acceptable imo, but backend drivers should be loaded as
> >> >> > backends get created by the tools (similarly frontend drivers
> >> >> > for the local attach case, though they should get auto-loaded
> >> >> > normally anyway).
> >> >> I tend to agree with you; I did it this way because that's what was 
> >> >> suggested to me.  But I don't at the moment know enough about the 
> >> >> backend creation stuff in xl / qemu to DTRT here.
> >> > 
> >> > The issue preventing autoloading here is that blktap is effectively
> >> > optional and libxl tries to do a best effort search for a usable disk
> >> > backend. If blktap is loaded the libxl will choose it, otherwise it will
> >> > fallback to qdisk. The problem is that if blktap is available but not
> >> > loaded then that is something which libxl cannot detect, I'm not sure
> >> > how we could go about fixing that.
> >> 
> >> Why not simply run a (series of) modprobe(s) from there? Or is
> >> that precluded by not being OS-neutral?
> > 
> > An interesting idea.
> > 
> > The blktap detection code is necessarily OS-specific. I previously
> > discounted it because of the possibility of a race between the
> > completion of modprobe and the driver actually registering enough for
> > detection to succeed. Maybe I was too pessimistic or someone has a
> > bright idea?
> 
> modprobe only exits when the driver's init function completed,
> at which point the driver can be expected to be in a usable state.

OK, so maybe that works then.

> >> The same would obviously apply to other backends (netback most
> >> notably).
> > 
> > We use netback unconditionally (there are no alternatives, at least not
> > ones we want to use (does qnet exist? not sure)) so I think the normal
> > driver autoloading ought to work there -- at least on kernels where it
> > exists, it was a relatively recent addition IIRC.
> 
> It was a recent addition, and I wonder whether calling this
> auto-loading really is the right term (unless I'm mis-understanding,
> you're referring to the xen-backend: module aliases) - what would
> trigger their loading? My current understanding of this it that it only
> allows loading the drivers without referring to a hard-coded driver
> module names.

My understanding was that creating a xenstore backend path would cause
the core generic xenstore backend code in the kernel to go "ah, I need a
driver for foo" (where foo is the backend name) and if one is not
already registered it will do the "modprobe foo" userspace event, which
the modaliases then cause to pickup the right kernel module.

Ian.


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