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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

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

Ian.


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