[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v4 0/7] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM
Hello, here is my fourth attempt at proposing an implementation of the memory_mapping DOMCTL for the ARM architecture. This patchset contains both the implementation of the hypercall and some related changes added after having the benefit of many comments to the previous attempts ([1]). I'm cutting the description a bit to avoid wasting too much of your time, but more details should be available, if needed, in the cover letter of the last proposal ([2]). The v1 patchset suffered from issues concerning correct typing and alignment of variables, and was implemented under the wrong assumption that dom0 could access any range of I/O memory; also, the hypercall was implemented as ARM32- specific, while it is not. The v2 patchset tried to fix these issues, when they were pointed out by Julien Grall, Eric Trudeau and Dario Faggioli. The v3 patchset tried to address some more issues indicated by Ian Campbell, Julien Grall, Jan Beulich and Dario Faggioli, and further discussed with Stefano Stebellini. The v2 patchset, in fact, did not perform any consistency check on an I/O-memory mapping before removing it. Also, the implementation of the hypercall for ARM provided with v2 was almost a complete copy of the x86 version: in v3 the code was made common between both architectures, abstracting out the different operations performed to map and unmap I/O memory. Also, the v2 patchset did not provide any way to specify the guest address range used to map the machine I/O-memory range indicated in the domU configuration with the "iomem" option; the v3 patchset added an optional parameter to that configuration option, allowing to specify the start guest address used for the mapping and defaulting to an 1:1 mapping in the absence of such parameter. Finally, the v2 patchset unconditionally called the new hypercall in the presence of the "iomem" option, while the v3 patchset attempted to restrict its use to the cases of ARM or HVM x86 guests. As of the v4 patchse, the first commit implements the bookkeeping necessary to make a domain's iomem_caps coherent with the I/O-memory mapping operations performed during domain build. With respect to v3, it attempts to improve the commit's description by specifying that, by now, the change is dom0-related, even if the modified function is generic, as pointed out by Julien Grall. The second commit adds to the apply_p2m_changes() function some consistency checks useful for the REMOVE operation. More in detail, the REMOVE switch of the function checks: . the validity of the mapping; . the fact that the mfn whose mapping is to be removed is actually mapped to the guest address given as parameter. With respect to v3, this commit attempts to address some issues indicated by Julien Grall. In fact, it removes an useless and slow lookup performed on start addresses only, and uses for each mapping the data already available in the pte. It also correctly increments the local variable used to keep the machine address whose mapping is currently being removed. It also lets the REMOVE switch return with an error, instead of just skipping the page, if the second of the above-described checks fails. The third commit modifies the interface of the existing map_mmio_regions() function for ARM according to a suggestion given in the discussion following the previous proposals by Julien Grall and confirmed by Jan Beulich. In fact, currently the function takes parameters of paddr_t type; this interface needs caller functions to correctly page-align addresses. This commit changes lets this function take page frame numbers as parameters instead, trying also to modify callers to use the new interface. The fourth commit moves the existing memory_mapping DOMCTL for x86 to xen/common/domctl.c and attempts to adapt the code to be used for both the x86 and ARM architecture. More in detail, the arch-specific operations necessary to map and unmap memory ranges are abstracted out in a pair of map_mmio_regions() and unmap_mmio_regions() functions. With respect to the corresponding one in v3, this commit attempts to address the following issues. . It uses a define for the paddr_bits symbol instead of a variable, as suggested by Julien Grall. . It defines common prototypes for the newly-introduced functions in a new common header, as suggested by Julien Grall. . It makes the signedness and type of some variables used in the new functions coherent with the ones previously defined in the x86 hypercall, as pointed out by Jan Beulich. The unmap_mmio_regions() function for x86 still has int as a return type to let the interface be coherent with the ARM version. . It clears p2m entries in map_mmio_regions() for x86 only in case of an error in set_mmio_p2m_entry(), as indicated by Jan Beulich. . It makes ranges considered in map_mmio_regions() and unmap_mmio_regions() for x86 inclusive of the end address, while they uncorrectly were not, as pointed out by Jan Beulich. . It removes some hard tabs turning them into spaces as suggested by Julien Grall. The fifth commit adds to libxl the handling code for a new optional paramter to the "iomem" configuration option. The new parameter, called "gfn", allows to specify the start guest address used for the mapping of the given machine address range. With respect to the v3 patchset, this commit addresses the following issues. . Adds the definition of a new LIBXL_HAVE_BUILDINFO_IOMEM_START_GFN macro to indicate the availability of the new option, as suggested by Dario Faggioli. . Simplifies the code by using a switch construct on the return value of the sscanf() function, instead of calling the function twice, which is unnecessary, as pointed out by Ian Campbell. . Adds a short paragraph to the manpage about the use of the iomem option to passthrough devices protected by an IOMMU, as suggested by Julien Grall. . Adds comments to the fields of the iomem structure as the meaning of "start" is ambiguous, as pointed out by Ian Campbell. The sixth commit adds two new architecture helpers to libxl, following a suggestion by Julien Grall. In fact, the v3 patchset allowed the newly-added DOMCTL to be called only for ARM or HVM x86 guests; the hypercall would be useful, instead, for all auto-translated guests, which include x86 PVH guests that are however classified as PV by libxl. The new architecture helpers should allow the caller to establish if a domain uses an auto-translated physmap. The seventh commit adds to libxl code to handle the iomem configuration option by invoking the memory_mapping DOMCTL. The hypercall is invoked only if the domain is auto-translated, as suggested by Julien Grall, by using the arch- specific helpers introduced with the previous commit. The code has been tested on a cubieboard2, with Linux v3.13 as a dom0 and ERIKA Enterprise ([3]) as a domU. Any feedback about this new version is more than welcome. Arianna [1] http://markmail.org/message/d5vhhiin5tr2yee7 http://markmail.org/message/dtzsvauzob332gnq http://markmail.org/message/fy7ioiv37gbp22an [2] http://lists.xen.org/archives/html/xen-devel/2014-03/msg01724.html [3] http://erika.tuxfamily.org/drupal/ Arianna Avanzini (7): arch, arm: domain build: let dom0 access I/O memory of mapped devices arch, arm: add consistency checks to REMOVE p2m changes arch, arm: let map_mmio_regions() take pfn as parameters xen, common: add the XEN_DOMCTL_memory_mapping hypercall tools, libxl: parse optional start gfn from the iomem config option tools, libxl: add helpers to establish if guest is auto-translated tools, libxl: handle the iomem parameter with the memory_mapping hcall docs/man/xl.cfg.pod.5 | 13 ++++--- tools/libxl/libxl.h | 10 ++++++ tools/libxl/libxl_arch.h | 2 ++ tools/libxl/libxl_arm.c | 5 +++ tools/libxl/libxl_create.c | 13 +++++++ tools/libxl/libxl_types.idl | 5 +-- tools/libxl/libxl_x86.c | 6 ++++ tools/libxl/xl_cmdimpl.c | 21 +++++++---- xen/arch/arm/domain_build.c | 18 ++++++++-- xen/arch/arm/gic.c | 21 ++++++----- xen/arch/arm/p2m.c | 49 ++++++++++++++++++++----- xen/arch/arm/platforms/exynos5.c | 13 ++++--- xen/arch/arm/platforms/omap5.c | 25 ++++++++----- xen/arch/arm/platforms/xgene-storm.c | 4 ++- xen/arch/x86/domctl.c | 70 ------------------------------------ xen/arch/x86/mm/p2m.c | 40 +++++++++++++++++++++ xen/common/domctl.c | 65 +++++++++++++++++++++++++++++++++ xen/include/asm-arm/p2m.h | 8 ++--- xen/include/asm-x86/p2m.h | 1 + xen/include/xen/p2m.h | 16 +++++++++ 20 files changed, 281 insertions(+), 124 deletions(-) create mode 100644 xen/include/xen/p2m.h -- 1.9.0 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |