[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC for-4.8 0/6] xen/arm: Add support for mapping mmio-sram nodes into dom0

Hello Edgar,

I have CCed a couple of people from ARM to get more input on it.

On 20/05/16 16:51, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxxx>

This series adds support for mapping mmio-sram nodes into dom0
as MEMORY, cached and with RWX perms.

Can you explain why you chose to map those nodes as MEMORY, cached and with RWX perms?

Dom0 can then choose to further restrict these mappings if needed.
We only look at the outer mmio-sram region. The sub-area nodes that
describe allocations within the mmio-sram region are only meaningful
to the guest AFAICT.

In an attempt to avoid growing the already fairly large domain_build.c
file, I've tried to implement a distributed way to deal with these kind
of special/custom mapping needs. These can live outside of domain_build.c
and are registerd by means of a .map method in the device_spec.

If this approach is not good, I'm happy to bin it and try something else.

We will have a similar problem when using ACPI for DOM0 or mapping a such MMIO to the guest. The hypercalls XENMAPSPACE_dev_mmio and XEN_DOMCTL_memory_mapping do not provide enough information to know the attribute to be used for mapping.

MMIO are always mapped in Stage-2 with Device_nGnRE, which is quite restrictive. This would also impact any MMIO regions, such as the video RAM buffer, that could be mapped write-combine.

After reading the ARM ARM (B2.8.2 ARM DII 0486.i), I think we could relax the stage-2 mapping by using Device_GRE for all the device MMIOs but the GIC.

We have to keep the GIC MMIO with the most restrictive memory attribute to avoid potential side-effect when Xen is switching between multiple vCPUs. All the other devices will be exclusive to a specific guest, so the guest can handle the device the way it wants. This may require some extra-care when reassigning the device to another domain.

Edgar, would Device_GRE be fine for you?

Note, that XENMAPSPACE_dev_mmio has been introduced in Xen 4.7 (which is due in a couple of weeks) and part of the stable ABI. So if it is not possible to relax the memory attribute, it might be worth to think fixing/reverting the hypercall for 4.7. Otherwise we would have to introduce a new one in the next release.


Julien Grall

Xen-devel mailing list



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