[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback


  • To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Tue, 27 Mar 2007 01:45:54 +0100
  • Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 26 Mar 2007 17:44:02 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdwB5uK2iXXG9v6Edu/NgAWy6hiGQAAarE+
  • Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback

On 27/3/07 01:33, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

>> That works fine for the x86 case.  But when it's auto-translated,
>> you won't even get a page fault in the guest because the guest PTE
>> is unchanged and completely valid.
> 
> How about you invalidate the PTE for the duration of the critical section.
> It's a bit skanky, but would work around this issue quite nicely!

As an arguably better alternative, perhaps we could simply make
XENMEM_add_to_physmap an atomic switch operation (from old mapping to new
mapping)? That is probably not a very hard thing to guarantee.

So you would XENMEM_add_to_physmap over the top of the existing grant
mapping, and expect the grant to simply 'fall away' as a result of this
operation (i.e., implicit removal from physmap triggers release of the
grant).

This sounds neat to me.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.