RE: [Xen-devel] [PATCH][HVM] Removing 1:1 mapping from qemu-dm

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

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