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] [PATCH] fix memory exchange hypercall.

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] fix memory exchange hypercall.
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Fri, 16 Mar 2007 12:25:17 +0900
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 15 Mar 2007 20:24:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C21F01A0.B8C4%keir@xxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070315133819.GE1819%yamahata@xxxxxxxxxxxxx> <C21F01A0.B8C4%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Thu, Mar 15, 2007 at 01:58:56PM +0000, Keir Fraser wrote:

> > - If the p2m entry is cleared which isn't followed by
> >   clearing PGC_allocaed and put_page() without any recording,
> >   there is no easy way to free the page until domain destruction.
> 
> This is true. Arguably guest_physmap_add_page() should test-and-clear
> PGC_allocated if there was already a page mapped at that address. Or it
> should fail. Or we should expect the guest not to do something this silly.
> 
> Really the correct answer is not immediately clear. I guess the first option
> makes most sense though, perhaps with a gdprintk(XENLOG_WARNING).

The ia64 p2m already adopted the first option without warning.
So the guest_physmap_remove_page() depends on PGC_allocated bit.
What's the expected behavior of guset_physmap_remove_page() with
PGC_allocated? It shouldn't touch the bit?

Thanks a lot for your clarification.
-- 
yamahata

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