[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


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
. 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
. 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

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

[1] http://markmail.org/message/d5vhhiin5tr2yee7
[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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.