Re: [PATCH] xencommons: Attempt to load blktap driver

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2012-05-16 at 08:47 +0100, Jan Beulich wrote:
> >>> On 15.05.12 at 18:40, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> > On 15/05/12 17:36, Jan Beulich wrote:
> >>>>> On 15.05.12 at 18:21, George Dunlap<george.dunlap@eu.citrix.com>  wrote:
> >>>   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).
> >> A host crash because of a driver not loaded? That would suggest
> >> bugs elsewhere...
> > Yes -- a bug in the AIO implementation for foreign pages, as the 
> > description states.
> 
> But if there's no backend driver, there shouldn't be any I/O at all,
> and hence no crash? Or are you saying that in the absence of the
> driver another (qdisk?) backend gets selected (which doesn't match
> my own observations, at least not as far as local attach to Dom0
> is concerned, and I would hope [expect] that backend selection
> doesn't depend on which domain the frontend lives in)?

backend selection depends on what drivers are available in the backend
domain, not the frontend domain.

libxl will try blktap(2) first and fallback to qdisk if blktap is not
present. The issue George is seeing is that qdisk can sometimes exercise
AIO bugs which cause host crashes. The fix is to try harder to use
blktap when it is really available by ensuring it gets loaded.

> Finally, loading "blktap" here is the right thing for pvops, but
> wrong for legacy/forward ported kernels - blktap2 would be
> the right module name there afaict. Perhaps, if this really is to
> go in (temporarily), loading an alias (devname: or xen-backend:,
> though the latter apears to be missing from the pvops driver)
> would be better here?

There is no blktap driver at all in mainline pvops, which is part of the
problem and the reason for falling back to qdisk. Which pvops driver do
you mean? To confuse matters there is a DKMS thing floating around which
works against modern kernels too.

Perhaps the right answer is (roughly) "modprobe blktap2 || modprobe
blktap"?

Ian.