[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



On Mon, 3 Jul 2017, Zhongze Liu wrote:
> Hi Jan,
> 
> 2017-07-03 22:25 GMT+08:00 Jan Beulich <JBeulich@xxxxxxxx>:
> >>>> On 30.06.17 at 22:15, <blackskygg@xxxxxxxxx> 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.

I thought that those two hypercalls were meant to be used for mem_access
and vm_event operations, as in xen/arch/arm/mem_access.c and
xen/arch/x86/mm/mem_access.c. The only caller is
tools/tests/xen-access/xen-access.c. They are enabled separatly as part
of the mem_access interface: their build is conditional to
CONFIG_HAS_MEM_ACCESS. Unless we want to move them from XENMEM_access_*
to DOMCTL_* operations, I don't think they could be used?

_______________________________________________
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®.