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