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

Re: [Xen-devel] [PATCH 6/6] Change MMU_PT_UPDATE_RESERVE_AD to support update page table for foreign domain


  • To: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Mon, 01 Jun 2009 10:20:06 +0100
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 01 Jun 2009 02:20:34 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acnh4J83XJstlRtsS9u8RG96aAW7awAoIXfQAAM2lcAAAXUgAAABlLc2
  • Thread-topic: [Xen-devel] [PATCH 6/6] Change MMU_PT_UPDATE_RESERVE_AD to support update page table for foreign domain

On 01/06/2009 09:40, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:

> Thanks for suggestion. I'm always nervous on API changes.
> 
> I'm still considering if any other potential usage mode for patch 5/6l (i.e.
> change page table or exchange memory for other domain),, but frustratedly
> realize no other requirement.

The API for XENMEM_exchange already permits specifying a foreign domain, so
you're just filling in the missing implementation. By the way I did not
check your implementation, but the major subtlety is that you must take care
for domains which are dying (d->is_dying). Giving new pages to such a domain
is generally a bug because you race domain_relinquish_resources() which is
walking the domain's page lists and freeing the pages. You therefore risk
leaving a zombie domain which will not die (refcount never zero).

See for example how that is handled with page_alloc.c for calls such as
XENMEM_populate_physmap, and how it is handled specially by
MMUEXT_PIN_L*_TABLE.

 -- 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®.