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

Re: [Xen-devel] [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes



Hi,

On 01/07/17 10:16, Zhongze Liu wrote:
On the ARM side, we are missing BUFFERABLE and WRITEALLOC. I don't know
how they map to these tags, which comes from the x86 world. Maybe we
should just add them separately as ARM only, like:

  /* bufferable, ARM only */
  #define XEN_DOMCTL_MEMATTRS_BUFFERABLE 0x08U
  /* write alloc, ARM only */
  #define XEN_DOMCTL_MEMATTRS_CACHE_WA   0x09U

Theoretically, we could say XEN_DOMCTL_MEMATTRS_UC means "BUFFERABLE" on
ARM and XEN_DOMCTL_MEMATTRS_SUC means "UNCACHED", because that's
actually what they correspond to I think. However using x86 names for
ARM caching attributes is very confusing and error prone. So I would
prefer introducing separate tags for ARM and x86. However, reusing
XEN_DOMCTL_MEMATTRS_UC, XEN_DOMCTL_MEMATTRS_CACHE_WT and
XEN_DOMCTL_MEMATTRS_CACHE_WB as Zhongze did in this proposal would be OK
for me.

When I read bufferable it is unclear if you speak about normal memory or device. I am looking at renaming the memory attribute with prefixing them with the type memory.

For instance BUFFERABLE would be renamed to NORMAL_NC...


Julien, what do you think?

I will only speak about ARM as my knowledge is very limited on x86.

For ARM, the resulting memory attribute is a combination of stage-1 and stage-2 (see Table D4-43 in ARM DDI 0487B.a). It adds further restriction to the memory attributes defined by the Guest in its page-tables.

This means that even the memory attribute used in stage-2 is normal cacheable, a guest is free to make it non-cacheable via stage-1 page table. This is not really clear in the description of the DOMCTL what is the real purpose. Is it restricting possibility of the guest?

Now, looking at the description, this domctl will be called after we mapped the RAM in the guest memory. So you will switch from write-back cacheable to another memory attribute. I think this will require cache maintainance to remove potential stall cache line.

Furthermore, you don't have any restriction on when this domctl will be called. It would be possible to call it when the guest is running or called on a range with memory attribute already changed. This will require some thoughts on how to do the cache maintenance.

Finally, Xen ARM64 will always have the whole RAM memory mapped in Xen with write-allocate memory attribute. This may result a memory attribute mismatch if the region is accessed by Xen (see B2.8).

This may take sometimes to get the implementation of the DOMCTL right. So I would rather focus to be able to share page between guest and an future-proof toolstack interface.

If you still have time at the end of the GSOC, you can look at using different memory attributes

Cheers,

--
Julien Grall

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

 


Rackspace

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