WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out i

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU)
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Thu, 1 Sep 2011 16:44:54 +0100
Cc: Todd Deshane <todd.deshane@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, David Vrabel <david.vrabel@xxxxxxxxxx>, Anthony Wright <anthony@xxxxxxxxxxxxxxx>
Delivery-date: Thu, 01 Sep 2011 08:45:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110901153823.GC7506@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <4E4E3957.1040007@xxxxxxxxxxxxxxx> <20110819125615.GA26558@xxxxxxxxxxxx> <4E56B132.9050708@xxxxxxxxxxxxxxx> <20110826142606.GA25511@xxxxxxxxxxxx> <20110826144438.GA24836@xxxxxxxxxxxx> <4E5E6843.7050206@xxxxxxxxxx> <20110831170711.GB13642@xxxxxxxxxxxx> <1314862972.28989.74.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110901142356.GD23971@xxxxxxxxxxxx> <1314889953.28989.130.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110901153823.GC7506@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-09-01 at 16:38 +0100, Konrad Rzeszutek Wilk wrote:
> > > > The flaw in the reasoning here is that you cannot take a kernel fault
> > > > while processing a hypercall, so hypercall arguments must have been
> > > > faulted in beforehand and that is what the sync_all was for.
> > > > 
> > > > It's probably fair to say that the Xen specific caller should take care
> > > > of that Xen-specific requirement rather than pushing it into common
> > > > code. On the other hand Xen is the only user and creating a Xen specific
> > > > helper/wrapper seems a bit pointless.
> > > 
> > > Perhaps then doing the vmalloc_sync_all() (or are more precise one:
> > > vmalloc_sync_one) should be employed in the netback code then?
> > 
> > Not just netback but everywhere which uses this interface.
> 
> Which is for right now netback :-). But yes - wherever we use that
> we should do follow with some sort of vmalloc.

blkback, xenbus_client and the grant table stuff all use it as well and
AFAICT have the same requirement for syncing.

$ git grep alloc_vm_area 
arch/x86/include/asm/xen/grant_table.h:#define xen_alloc_vm_area(size)  
alloc_vm_area(size)

-- this macro is unused...

arch/x86/xen/grant-table.c:                     xen_alloc_vm_area(PAGE_SIZE * 
max_nr_gframes);
drivers/block/xen-blkback/xenbus.c:     blkif->blk_ring_area = 
alloc_vm_area(PAGE_SIZE);
drivers/net/xen-netback/netback.c:      vif->tx_comms_area = 
alloc_vm_area(PAGE_SIZE);
drivers/net/xen-netback/netback.c:      vif->rx_comms_area = 
alloc_vm_area(PAGE_SIZE);
drivers/xen/xenbus/xenbus_client.c:     area = xen_alloc_vm_area(PAGE_SIZE);

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>