From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) Date: Wed, 31 Aug 2011 13:07:11 -0400 Message-ID: <20110831170711.GB13642@dumpdata.com> References: <4E31820C.5030200@overnetdata.com> <1311870512.24408.153.camel@cthulhu.hellion.org.uk> <4E3266DE.9000606@overnetdata.com> <20110803152841.GA2860@dumpdata.com> <4E4E3957.1040007@overnetdata.com> <20110819125615.GA26558@dumpdata.com> <4E56B132.9050708@overnetdata.com> <20110826142606.GA25511@dumpdata.com> <20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4E5E6843.7050206@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: David Vrabel Cc: Ian Campbell , Todd Deshane , "xen-devel@lists.xensource.com" , Anthony Wright List-Id: xen-devel@lists.xenproject.org On Wed, Aug 31, 2011 at 05:58:43PM +0100, David Vrabel wrote: > On 26/08/11 15:44, Konrad Rzeszutek Wilk wrote: > > > > So while I am still looking at the hypervisor code to figure out why > > it would give me [when trying to map a grant page]: > > > > (XEN) mm.c:3846:d0 Could not find L1 PTE for address fbb42000 > > It is failing in guest_map_l1e() because the page for the vmalloc'd > virtual address PTEs is not present. > > The test that fails is: > > (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) != _PAGE_PRESENT > > I think this is because the GNTTABOP_map_grant_ref hypercall is done > when task->active_mm != &init_mm and alloc_vm_area() only adds PTEs into > init_mm so when Xen looks in the page tables it doesn't find the entries > because they're not there yet. > > Putting a call to vmalloc_sync_all() after create_vm_area() and before > the hypercall makes it work for me. Classic Xen kernels used to have > such a call. That sounds quite reasonable. > > This presumably works on some systems/configuration and not others > depending on what else is using vmalloc(). i.e., if another kernel > thread (?) calls vmalloc() etc. then there will be a page for vmalloc > area PTEs and it will work. > > I'll try and post a patch tomorrow. > > Thanks to Ian Campbell for pointing me in the right direction. Great! Thanks for hunting this one down. > > David