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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.05.16 at 15:24, <julien.grall@xxxxxxx> wrote:
> 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.

Option 2 is clearly worse. I view option 3 as a possibility, but only if
option 1 turns out too intrusive or some such.

However, using the top bits of space doesn't look a very nice way
to address this. How about defining one attribute which would
always get used by XENMEM_add_to_physmap (perhaps the one
that gets used it is right now), and supporting a wider range only
through XENMEM_add_to_physmap_batch? Background being that
the latter has an unused (currently ignored) field, which you could
utilize: foreign_domid. Of course that would then need to be
renamed in a backward compatible way (to something more generic,
e.g. "aux"), and we should try to remember to avoid the same
mistake that was made when that sub-op was added and again
when XENMAPSPACE_dev_mmio got introduced: New operations
should not ignore fields, so they can get a meaning assigned later
on.

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

Not sure what lightweight version you think of here, or how you
would mean to make a hypercall "warn" - it can only return success
or an error.

Jan


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