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

[Julien Grall <julien.grall@xxxxxxx>]

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

--
Julien Grall

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