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][HVM] Removing 1:1 mapping from qemu-dm

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH][HVM] Removing 1:1 mapping from qemu-dm
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Wed, 28 Jun 2006 10:33:08 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 28 Jun 2006 10:33:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: AcaayFfZ/q7zwp81TaCPzCxpoerZ9QAAf5fw
Thread-topic: [Xen-devel] [PATCH][HVM] Removing 1:1 mapping from qemu-dm
Keir Fraser wrote:
> On 28 Jun 2006, at 16:15, Nakajima, Jun wrote:
> 
>> Since the write refcount in type_info can change at any time now
>> because of map/unmap by qemu-dm at runtime, I stopped using it to
>> avoid a hack in mm.c. The extra code is a scaled-down version of
>> write refcount dedicated for guest page table pages, and I think 4
>> bits would be sufficient in normal cases because normal guests don't
>> establish that many translations (i.e. using different virtual
>> addresses) against page table pages. 
>> 
>> Since the number cannot exceed the length of the shadow hash chains
>> anyway, I can add an extra logic that detects overflow and scans the
>> entire chains if detected. With this we can just have a 2-bit ref
>> count, 0 - no, 1 (most cases), and 2 - more than one.
> 
> I'd prefer the hack in mm.c I think. It's certainly much smaller, and
> it'd be okay with a comment. Is there any way for get/put_page_type to
> know if they've been called on a shadow page (as opposed to a guest
> page) and to avoid changing the type count based on that, rather than
> whether the page is local or foreign? That'd be a neater and less
> hacky thing to use for the decision imo.
> 

Basically we need to tell the parent L1 (or top) page that has a
reference to it, for example. If it's a shadow page, the guest page is
being used in the shadow tree. It would be doable for get_page_type, but
almost impossible for put_page_type given it gets only one argument
(page_info) today.

And actually local vs. foreign does not work well because we need to
terminate and clean up guests from foreign as well. 

What we need is:
1. Don't change type_info in get/put_page_type if the owner domain is in
shadow translate mode,
2. Make special get/put_page_type that can change type_info, and they
are called only in shadow page table context. 

Jun
---
Intel Open Source Technology Center

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