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] A question about SHARE_PFN_WITH_DOMAIN

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-devel] A question about SHARE_PFN_WITH_DOMAIN
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 12 Jan 2006 10:33:23 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 12 Jan 2006 10:33:59 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD802C06C5A@pdsmsx403>
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: <571ACEFD467F7749BC50E0A98C17CDD802C06C5A@pdsmsx403>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 12 Jan 2006, at 08:20, Tian, Kevin wrote:

I know the purpose of it is to share xenheap pages with domain, so with
ownership change, type/count info update, etc. But is there any reason
we can not allocate them from domheap instead, to grant ownership
directly, since from the very start we know them shared between Xen and
doman? Currently I just saw several types of pages are following this
path:
        - shared info page
        - grant table
        - trace buffer

Maybe I missed some important hints about usage of domheap and xenheap
there? ;-)

Well, there were originally two reason for allowing a guest to own xenheap pages:

Firstly, a domain page was only accessible in Xen/x86_32 with map_domain_page(), which is only intended for very short-term mappings. I added map_domain_page_global() as a temporary interface until current offenders who create long-term mappings of domheap pages are fixed. In fact, we could keep that as a permanent interface (if we created lots of domains we would probably run out of xen heap before we run out of domain_page_global mapping space).

Secondly, there is the subtle and thorny issue of domain destruction. Xen assume that any domain that has a non-zero reference count has a valid shared_info, for example. If we made shared_info a normal domheap page, and simply had Xen inc that page's refcnt like any other user, we would have a problem. Xen could not drop its reference until the domain refcnt drops to zero, but that won't happen until the domain owns no more pages!

We could work around that second issue with a new page flag to indicate pages that should not be freed to the heap when their refcnt drops to zero. Then Xen could set that flag instead of inc'ing the refcnt. That would allow the domain refcnt to fall to zero and Xen can then explicitly clear the flag and free the page in the domain destructor.

There's also the issue of whether these pages should be included in the domain's page count, and whether they should appear in its pseudo-phys space. If those issues get special-cased too, which they may need to for backward compatibility, the solution may end up as complex as the current xenheap-ownership solution.

 -- Keir


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