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

[Zhongze Liu <blackskygg@gmail.com>]

Hi Jan,

2017-07-03 22:25 GMT+08:00 Jan Beulich <JBeulich@suse.com>:
>>>> On 30.06.17 at 22:15, <blackskygg@gmail.com> wrote:
>> /*
>>  * Set access permissions, cacheability and shareability (ARM only) of a
>>  * continuos range of normal memory (RAM) in the stage-2 page table.
>>  */
>> /* XEN_DOMCTL_memattrs_op */
>>
>> /* set chacheability and shareability */
>> #define XEN_DOMCTL_MEMATTRS_OP_SET_CACHEATTRS  1
>> /* set access permissions */
>> #define XEN_DOMCTL_MEMATTRS_OP_SET_PERMISSIONS 2
>> /* get chacheability and shareability */
>> #define XEN_DOMCTL_MEMATTRS_OP_GET_CACHEATTRS  1
>> /* get access permissions */
>> #define XEN_DOMCTL_MEMATTRS_OP_GET_PERMISSIONS 2
>>
>> /* flags for XEN_DOMCTL_MEMATTRS_OP_SET_CACHEATTRS */
>> /* chacheability flags, the values happen to be the same with those in
>>  * x86 PAT.  (See [4])
>>  */
>> /* uncacheable */
>> #define XEN_DOMCTL_MEMATTRS_UC         0x00U
>> /* write combine, x86 only */
>> #define XEN_DOMCTL_MEMATTRS_CACHE_WC   0x01U
>> /* write through */
>> #define XEN_DOMCTL_MEMATTRS_CACHE_WT   0x04U
>> /* write protect, x86 only */
>> #define XEN_DOMCTL_MEMATTRS_CACHE_WP   0x05U
>> /* write back */
>> #define XEN_DOMCTL_MEMATTRS_CACHE_WB   0x06U
>> /* strong uncacheable, x86 only*/
>> #define XEN_DOMCTL_MEMATTRS_SUC        0x07U
>
> I think if we really want to go this route, this part should mean
> removal of DOMCTL_pin_mem_cacheattr then. However, ...
>
>> /* shareability flags (See [5]), arm only, the value is taken from
>>  * asm-arm/page.h, but live in the second 8-bit.
>>  */
>> #define XEN_DOMCTL_MEMATTRS_SHAREABILITY_SHIFT 8
>> #define XEN_DOMCTL_MEMATTRS_SH_NON_SHAREABLE (LPAE_SH_NON_SHAREABLE<<8)
>> #define XEN_DOMCTL_MEMATTRS_SH_UNPREDICTALE  (LPAE_SH_UNPREDICTALE<<8)
>> #define XEN_DOMCTL_MEMATTRS_SH_OUTER         (LPAE_SH_OUTER<<8)
>> #define XEN_DOMCTL_MEMATTRS_SH_INNER         (LPAE_SH_INNER<<8)
>>
>> /* flags for XEN_DOMCTL_MEMATTRS_OP_SET_PERMISSIONS */
>> #define XEN_DOMCTL_MEMATTRS_ACCESS_N         0x00U
>> #define XEN_DOMCTL_MEMATTRS_ACCESS_R         (0x01U<<0)
>> #define XEN_DOMCTL_MEMATTRS_ACCESS_W         (0x01U<<1)
>> #define XEN_DOMCTL_MEMATTRS_ACCESS_X         (0x01U<<2)
>> #define XEN_DOMCTL_MEMATTRS_ACCESS_RW        \
>> (XEN_DOMCTL_MEMATTRS_ACCESS_R|XEN_DOMCTL_MEMATTRS_ACCESS_W)
>> #define XEN_DOMCTL_MEMATTRS_ACCESS_RX        \
>> (XEN_DOMCTL_MEMATTRS_ACCESS_R|XEN_DOMCTL_MEMATTRS_ACCESS_X)
>> #define XEN_DOMCTL_MEMATTRS_ACCESS_WX        \
>> (XEN_DOMCTL_MEMATTRS_ACCESS_W|XEN_DOMCTL_MEMATTRS_ACCESS_X)
>> #define XEN_DOMCTL_MEMATTRS_ACCESS_RWX        \
>> (XEN_DOMCTL_MEMATTRS_ACCESS_RW|XEN_DOMCTL_MEMATTRS_ACCESS_X)
>
> ... with this basically duplicating
> XENMEM_access_op_{set,get}_access I now wonder whether
> we don't already have all you need (apart from an ARM variant of
> DOMCTL_pin_mem_cacheattr).

In fact, there isn't much description on the usage of this
interface, so I turned to the implementation in
xen/common/mem_access.c, where I see this
interface invoking  p2m_set_mem_acess, which further invokes
set_mem_acess and finally
p2m->set_entry(), so I guess this might be the right interface to use.
To confirm the guess, I turned to Stabellini for help, and he told me
that XENMEM_access_op
is "for getting very detail info on what the guest is accessing", and
might not be suitable
for this scenario, so I just gave up using it, and that's why I have this RFC.
I'll re-confirm this with Stabellini.

>
> This being an RFC, I'll skip pointing out various cosmetic issues with
> your proposal.
>
> Jan
>

Thank you.


Cheers,

Zhongze Liu

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