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

[Julien Grall <julien.grall@arm.com>]

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