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@lists.xen.org
https://lists.xen.org/xen-devel
