[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