[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v11 00/14] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM
Hello, here is the eleventh version of my implementation proposal for the DOMCTL memory_mapping for the ARM architecture. As usual, I'll try to keep this as short as I can by just going through the most relevant changes. A more detailed changelog is in the description of each of the commits, while an extensive summary of the patch series' genesis can be found in the last full cover letter ([1]). Please note that this patchset includes a contribution from Andrii Tseglytskyi, as you may also see from the shortlog below. Patch 0001 has been fixed according to suggestions given by Julien Grall and approved by Ian Campbell. Now it handles even level 3 mappings. Also, as suggested by Andrew Cooper, the printk uses a XENLOG_G_WARNING loglevel so that it can be rate-limited appropriately. Patch 0002 has also been changed according to directives provided by Julien Grall. Now partially-mapped memory regions are unmapped regardless of their being I/O-memory or not. Patch 0008 has been fixed according to directive from Julien Grall. Patch 0010 has been added to allow FLASK to handle the memory_mapping case also on ARM architecture, therefore preventing wrong error messages from being printed, as indicated by Julien Grall. A new patch 0011, contributed by Andrii Tseglytskyi, has been merged into the series. It adds a FLASK policy rule to allow a domU to access previously- mapped I/O-memory regions. Patch 0012 has been modified according to suggestions provided by Ian Campbell. The VGA-related bits have been moved to a libxl_pci helper. Non-functional changes have been split into patch 0013 to facilitate review. A leftover debug print has been removed. As usual, the code has again been tested on a cubieboard2, with Linux v3.15-rc3 as a dom0 and ERIKA Enterprise ([3]) as a domU. The x86 bits have been tested on an x86_64 machine with Linux 3.15.0-rc5 as both dom0 and domU. Any feedback about this new version of the patchset is more than welcome, Arianna [1] http://lists.xen.org/archives/html/xen-devel/2014-03/msg01724.html [2] http://markmail.org/message/7t6erxfy7pgorakb [3] http://erika.tuxfamily.org/drupal/ Andrii Tseglytskyi (1): flask/policy: allow domU to use previously-mapped I/O-memory Arianna Avanzini (13): arch/arm: add consistency check to REMOVE p2m changes arch/arm: unmap partially-mapped memory regions arch/x86: warn if to-be-removed mapping does not exist arch/x86: cleanup memory_mapping DOMCTL xen/common: add ARM stub for the function memory_type_changed() xen/x86: factor out map and unmap from the memory_mapping DOMCTL xen/common: move the memory_mapping DOMCTL hypercall to common code tools/libxl: parse optional start gfn from the iomem config option tools/libxl: handle the iomem parameter with the memory_mapping hcall xsm/flask: avoid spurious error messages when mapping I/O-memory tools/libxl: explicitly grant access to needed I/O-memory ranges tools/libxl: cleanup the do_pci_add() function xen/common: do not implicitly permit access to mapped I/O memory docs/man/xl.cfg.pod.5 | 18 ++- tools/flask/policy/policy/modules/xen/xen.te | 1 + tools/libxc/xc_domain.c | 10 ++ tools/libxl/libxl.h | 10 ++ tools/libxl/libxl_create.c | 28 +++- tools/libxl/libxl_internal.h | 3 + tools/libxl/libxl_pci.c | 213 +++++++++++++++++---------- tools/libxl/libxl_types.idl | 4 + tools/libxl/xl_cmdimpl.c | 17 ++- xen/arch/arm/p2m.c | 44 +++++- xen/arch/x86/domctl.c | 76 ---------- xen/arch/x86/mm/p2m.c | 57 ++++++- xen/common/domctl.c | 54 ++++++- xen/common/memory.c | 2 +- xen/include/asm-arm/p2m.h | 13 +- xen/include/asm-x86/p2m.h | 3 +- xen/include/xen/p2m-common.h | 16 ++ xen/xsm/flask/hooks.c | 2 +- 18 files changed, 385 insertions(+), 186 deletions(-) create mode 100644 xen/include/xen/p2m-common.h -- 2.1.0 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |