[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/1] Xen PV support for hugepages
>>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |