From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] xencommons: Attempt to load blktap driver Date: Tue, 15 May 2012 17:40:41 +0100 Message-ID: <4FB28709.9080001@eu.citrix.com> References: <4FB29D6F0200007800083E81@nat28.tlf.novell.com> <4FB28295.8020905@eu.citrix.com> <4FB2A2320200007800083EB4@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FB2A2320200007800083EB4@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 15/05/12 17:36, Jan Beulich wrote: >>>> On 15.05.12 at 18:21, George Dunlap wrote: >> On 15/05/12 17:16, Jan Beulich wrote: >>>>>> On 15.05.12 at 17:49, George Dunlap 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 >>>> >>>> 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. > No, I won't. > >> 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. -George