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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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.
If you want to volunteer to do a patch that DTRT, I think it makes sense 
to hold off.  But if not, I suggest we accept this patch, and I'll come 
back and try to write a proper one before the 4.2 release.  I think it's 
really important we do something before 4.2, as it causes pretty serious 
problems on systems which are affected (almost always a host crash, 
possibly with some disk corruption).
 -George

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