[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |