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

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

Hi Jan,

On 24/05/16 14:57, Jan Beulich wrote:
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
      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

That is a good idea. For Xen 4.7, I am suggesting to:
- Document the behavior of XENMEM_add_to_physmap for ARM. I.e it will always use Device_nGnRE (we could use a less weaker one but I am not confident enough for a such change before the release). - Check the foreign_id is always with XEMEM_add_to_physmap_batch. The memory attribute associated will be the same as XENMEM_add_to_physmap.

The number of memory attribute supported will be extend after the release for Xen 4.8.

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.

Let say we only support one kind of memory attribute for Xen 4.7. When we will introduce new one, Linux may use them and therefore the mapping will fail.

We can either fix by letting Linux try different memory attribute. Or use a default one in Xen.


Julien Grall

Xen-devel mailing list



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