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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

Jan


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