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

[Xen-devel] [for-4.7] Request input on XENMAPSPACE_dev_mmio

Hi all,

Sorry for noticing this problem late in the release process.

The mapping space XENMAPSPACE_dev_mmio has been introduced recently (will be present in Xen 4.7) to let dom0 map device MMIO regions when ACPI is in-use on ARM platform.

Xen ARM will map those regions in the stage-2 page table using the memory attribute Device_nGnRE (i.e non-Gathering, non-Reordering, no-unaligned access).

The final memory attribute is a combination of stage-1 (handled by the kernel) and stage-2 attributes. It will always result to a restrictive memory attribute (see D4.4.3 in ARM DDI 0487A.i).

Device_nGnRE is one of the most restrictive memory attribute, whilst it fits in lot of case, the performance are not great on device such as graphic cards, and it makes impossible to access those regions with unaligned access (a lot of Linux drivers uses memcpy which does unaligned access).

Unfortunately it is not possible to find a weaker memory attribute that would fit for everyone. For instance, we would need to map static RAM with normal memory attribute to allow speculation and unaligned access.

However, the same normal memory could not be used for MMIOs having side-effect (such as an UART) because the processor would be allowed to fetch additional memory locations.

For more details about the different memory attributes see B2.8 in ARM DDI 0487A.i.

In the case of ACPI, only DOM0 has access to the full description of the device and know the memory attribute to use. So we need to expand XENMAPSPACE_dev_mmio to provide the memory attribute (this could be done using the top bits of 'space').

For ARM we would need at least the following attributes:
  - normal uncached memory: for write-combine on SRAM or video RAM
  - Device_nGnRE: non-gathering and non-reordering
  - Device_GRE: gathering and redordering

It might be worth to also consider "normal cache memory".

Xen 4.7 will be release very soon (~ couple of weeks), so we have few solutions:
    1) Extend XENMAPSPACE_dev_mmio for Xen 4.7
2) Wait for Xen 4.8 to fix it: this may require to introduce a new space to be backward compatible. 3) Revert XENMAPSPACE_dev_mmio for Xen 4.7 and re-introduce it properly on Xen 4.8: It is only used by ACPI on ARM which is a tech preview.

I would lean toward the solution 1) to avoid delaying ACPI support for ARM and avoid introducing an sub-hypercall which does not fit for our usage.

I think the space could be extend in a lightweight version for Xen 4.7 by introducing only one memory attribute and warn on any other value.

Do you have any opinions on the way to fix it? I can provide a patch as soon as possible.


Julien Grall

Xen-devel mailing list



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