>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 05.11.08 11:59 >>>
>On 4/11/08 15:41, "dcm@xxxxxxxx" <dcm@xxxxxxxx> wrote:
>
>> This is the latest version of a patch that adds hugepage support to the Xen
>> hypervisor in a PV environment. It is against the latest xen-unstable tree
>> on xenbits.xensource.com. I believe this version addresses the comments
>> made about the previous version of the patch.
>>
>> Hugepage support must be enabled via the hypervisor command line option
>> "allowhugepage".
>>
>> It assumes the guest guarantees that the hugepage is physically aligned and
>> contiguous.
>>
>> There is currently no support in the tools for saving/restoring/migrating
>> guests who use hugepages.
>>
>> Note to the maintainers: What else needs to be done for this patch to be
>> considered for inclusion into the tree?
>
>I cleaned it up, fixed some return codes, and applied as c/s 18756. It may
>be worth Jan Beulich taking a quick look as the return-code conventions for
>the get/put functions in mm.c is now rather convoluted. I think I got it
>right but I'm not 100% sure. Indeed, Jan, it'd sure be nice to have some
>comments explaining what the <0,=0,>0 codes mean from the various get/put
>functions, and how they differ between the l1e variants and the others (I'm
>pretty sure they do differ).
The return value handling seems correct, but the call to map_pages_to_xen()
at the end of get_page_from_l2e() doesn't: Simply or-ing the guest-provided
flags into PAGE_HYPERVISOR definitely isn't correct. The cache attributes
must be extracted, converted to L1 notion, and then be or-ed in.
Also, the special code to deal with LDT pages in put_page_from_l1e() should
now also be required in put_page_from_l2e(). Perhaps that logic could be
moved into put_data_page()?
Further, with L2_DISALLOW_MASK now permitting _PAGE_PSE, the use
site in mod_l2_entry() must certainly also be modified, i.e. the subsequent
l2e_has_changed() would need to include _PAGE_PSE, and the case of
_PAGE_RW toggling when _PAGE_PSE was and will be set needs to be
taken care of.
Next, adjust_guest_l2e() would apparently also need to be modified.
Finally, no longer hiding X86_FEATURE_PSE from the guest seems rather
risky: I'm pretty sure the pv-ops kernel relies on this flag being clear - when
set, it would blindly (i.e. without ensuring the underlying memory is
contiguous and suitably aligned) try to use 2Mb mappings for e.g. the 1:1
mapping. I would think this capability ought to be propagated by another
means. Likewise I'm uncertain about letting X86_CR4_PSE shine through.
And a general question: How is a trivial DomU going to be able to make
use of this, without being permitted to allocate non-order-zero chunks of
memory?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home