Re: [Xen-devel] [PATCH v5 8/8] tools, libxl: handle the iomem parameter with the memory_mapping hcall

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Mon, 2014-04-07 at 01:32 +0200, Arianna Avanzini wrote:
> Currently, the configuration-parsing code concerning the handling of the
> iomem parameter only invokes the XEN_DOMCTL_iomem_permission hypercall.
> This commit lets the XEN_DOMCTL_memory_mapping hypercall be invoked
> after XEN_DOMCTL_iomem_permission when the iomem parameter is parsed
> from a domU configuration file, so that the address range can be mapped
> to the address space of the domU. The hypercall is invoked only in case
> of domains using an auto-translated physmap.

I suppose http://article.gmane.org/gmane.comp.emulators.xen.devel/194504
applies here, hence this patch and patch #7 haven't changed this time
round.

IIRC the main issue to be decided is the one from:
http://article.gmane.org/gmane.comp.emulators.xen.devel/193808 and
http://article.gmane.org/gmane.comp.emulators.xen.devel/194058 .

The question is whether XEN_DOMCTL_memory_mapping should also implicitly
grant permissions to the region or if it should require that a call to
XEN_DOMCTL_iomem_permission has already been made.

In the former case (implicitly granting) the calls to
xc_domain_memory_mapping replace xc_domain_iomem_permission in this
patch instead of being added.

In the latter case (require iomem_perm first) then te
iomem_permit_access should be removed from the
XEN_DOMCTL_memory_mapping implementation and be replaced with a
permissions check instead of grant. We'd also want to make sure that
e.g. libxl_pci.c was making the correct xc_domain_iomem_permission calls
to subsequently allow qemu to use xc_domain_memory_mapping (which would
mean refactoring do_pci_add to make those calls for both HVM and PV
guests, AFAICT).

Although the first change seems simpler the second way has the advantage
of separating the permission from the mapping, which might be beneficial
because it handles the case of two mappings of the same thing better. It
might also have implications for XSM and the separation of privilege
into toolstack and qemu.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel