Message ID | 20240430165845.81696-1-roger.pau@citrix.com (mailing list archive) |
---|---|
Headers | show |
Series | xen/x86: support foreign mappings for HVM | expand |
Hi Roger, On Tue, 2024-04-30 at 18:58 +0200, Roger Pau Monne wrote: > Hello, > > The following series attempts to solve a shortcoming of HVM/PVH > guests > with the lack of support for foreign mappings. Such lack of support > prevents using PVH based guests as stubdomains for example. > > Add support in a way similar to how it was done on Arm, by iterating > over the p2m based on the maximum gfn. > > Mostly untested, sending early in case it could be considered for > 4.19. In case of it will be properly tested I think we can consider this patch as a candidate for 4.19 ~ Oleksii > > Thanks, Roger. > > Roger Pau Monne (2): > xen/x86: account for max guest gfn and number of foreign mappings > in > the p2m > xen/x86: remove foreign mappings from the p2m on teardown > > CHANGELOG.md | 1 + > xen/arch/x86/domain.c | 6 +++ > xen/arch/x86/include/asm/p2m.h | 28 ++++++++++---- > xen/arch/x86/mm/p2m.c | 70 > ++++++++++++++++++++++++++++++++-- > 4 files changed, 94 insertions(+), 11 deletions(-) >
On Tue, Apr 30, 2024 at 06:58:43PM +0200, Roger Pau Monne wrote: > Hello, > > The following series attempts to solve a shortcoming of HVM/PVH guests > with the lack of support for foreign mappings. Such lack of support > prevents using PVH based guests as stubdomains for example. > > Add support in a way similar to how it was done on Arm, by iterating > over the p2m based on the maximum gfn. > > Mostly untested, sending early in case it could be considered for 4.19. I've now tested this using the following dummy XTF test: void test_main(void) { unsigned long idxs = 0; xen_pfn_t gpfns = 0; int errs = 0, error; struct xen_add_to_physmap_batch add = { .domid = DOMID_SELF, .space = XENMAPSPACE_gmfn_foreign, .u.foreign_domid = 0, .size = 1, .idxs.p = &idxs, .gpfns.p = &gpfns, .errs.p = &errs, }; error = hypercall_memory_op(XENMEM_add_to_physmap_batch, &add); if ( error || errs ) xtf_error("add_to_physmap_batch failed: %d (errs: %d)\n", error, errs); while ( 1 ); xtf_success(NULL); } And avoiding some of the permissions checks in Xen so that an arbitrary domU could map dom0 gfn 0. I see count_info increasing by 1 until the XTF guest is killed, at which point the count_info goes back to the value previous to the map. Regards, Roger.