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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

The same would obviously apply to other backends (netback most
notably).

Jan


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