Re: [for-4.7] Request input on XENMAPSPACE_dev_mmio

[Wei Liu <wei.liu2@citrix.com>]

On Tue, May 24, 2016 at 02:24:22PM +0100, Julien Grall wrote:
> 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.
> 

My preference is 1>3>2, fwiw.

After looking at the code, my gut feeling is that 1 is not going to be
overly intrusive -- there seems to be only a handful of function in Xen
on ARM to handle MMIO mapping.

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

We should just reject the values that are not supported yet imho.

Wei.

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