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/
Home Products Support Community News


RE: [Xen-devel] A question about SHARE_PFN_WITH_DOMAIN

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] A question about SHARE_PFN_WITH_DOMAIN
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 13 Jan 2006 15:10:51 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 13 Jan 2006 07:17:41 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYXYwr/7m1nWrp7Qb62yrIppszpVAAnp5iw
Thread-topic: [Xen-devel] A question about SHARE_PFN_WITH_DOMAIN
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2006年1月12日 18:33
>On 12 Jan 2006, at 08:20, Tian, Kevin wrote:
>> 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:

Thanks, and that does help!

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

A good hint for later development on common code. ;-) I didn't realize access 
to domheap being an issue on x86_32, since there's enough virtual space on 
64bit platform and thus map_domain_page is simply defined as __va on them. Yes, 
permanent mapping is not scalable here. 

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

Could you please point out where I can find such assumption in the code?

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

Or to set initial refcnt of such type of page to '2', indicating both Xen and 
domain have reference upon it. Whenever Xen want to drop the refcnt, safe to do 
since domain still holds on. Later when destructing domain, another drop 
happens and then freed to heap.

>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

I see the necessity now.

Thanks a lot,

Xen-devel mailing list