|
[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 Stefano,
Added Julien and removed those who are mistakenly Cc'ed :-)
will never try to draft emails half asleep again.
2017-07-01 5:48 GMT+08:00 Stefano Stabellini <sstabellini@xxxxxxxxxx>:
> On Sat, 1 Jul 2017, Zhongze Liu wrote:
>> ********************************************************************************
>> DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes
>>
>> Zhongze Liu
>> <blackskygg@xxxxxxxxx>
>>
>> ********************************************************************************
>> Motivation and Description
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> During the dicussion about the proposal "allow setting up shared memory areas
>> between VMs from xl config file" (see [1]), it's getting clear that when we
>> setup shared memory areas for VM communications from xl config file, we would
>> appreciate the ability to control the permissions and some attributes of the
>> shared memory pages: in the simplest the cases, regular cacheable RAM with
>> read
> ^ of
>
>> write permissions will be enough (For ARM, it would be p2m_ram_rw and
>> MATTR_MEM,
>> LPAE_SH_INNER). But there are also complicated cases where we might need
>> deeper
>> control over the permissions, cacheability and shareability of the shared RAM
>> pages to meet some extra requirements (see [2]). And this could be done via
>> playing with the stage-2 page tables, on both x86 and ARM.
>>
>> So there comes to the need for a DOMCTL that can set the permissions and
>> attributes (currently, only cacheability and shareability is in the plan) of
>> a
>> given RAM page in the stage-2 page talbes. The only related work can be seen
>> so
> ^ tables
>
Sorry for all the typos in this proposal. I'll fix them later.
>
>> far is DOMCTL_pin_mem_cacheattr (see [3]), which is for controlling the
>> cacheability of pages and is x86 HVM only. There seems to be no arch-neutral
>> DOMCTL interfaces that can meet our requirements.
>>
>> That's why we need a new arch-neutral DOMCTL, which is tentatively called
>> DOMCTL_mem_attrs_op in this proposal and would enable us to control the
>> access
>> permissions, cacheability and shareability (ARM only) attributes of RAM
>> pages.
>>
>> ********************************************************************************
>> Interface Specification
>> ~~~~~~~~~~~~~~~~~~~~~~~
>>
>> A current draft of the interface looks like this:
>>
>> /*
>> * 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 */
> ^ cacheability
>
>
>> #define XEN_DOMCTL_MEMATTRS_OP_SET_CACHEATTRS 1
>> /* set access permissions */
>> #define XEN_DOMCTL_MEMATTRS_OP_SET_PERMISSIONS 2
>> /* get chacheability and shareability */
> ^ cacheability
>
>> #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
> ^ cacheability
>
>> * 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
>
> 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.
>
> Julien, what do you think?
>
sorry for missing the 'write-allocate' flag for ARM. I agree with you
in adding some
ARM-only flags, coz using x86 terminologies does look confusing. But
let's hear what other
maintainers say.
>
>> /* 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)
>
> We don't need UNPREDICTALE as a possible value :-)
>
Will remove this.
>
>> #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)
>>
>> struct xen_domctl_memattrs_op {
>> int op; /* IN XEN_DOMCTL_MEMATTRS_OP_* */
>
> uint32_t: we only use explicitly sized integers in hypercalls
>
Ok, I'll make it an uint32_t.
>
>> xen_pfn_t first_gfn; /* IN first page in range */
>> uint32_t nr_gfns; /* IN number of pages in range */
>>
>> XEN_GUEST_HANDLE(uint32_t) attrs; /* IN/OUT per-page attrs */
>
> XEN_GUEST_HANDLE is used for pointers in struct (typically for arrays).
> In this case, I don't think we need a pointer, we could just have a
> single uint32_t to specify the permissions and attributes for all the
> pages in the range.
>
I'm not sure about this.
I think using an array here and below will make the hypercall more flexible --
similar to XENMEM_add_to_physmap_batch.
But according to our needs, using one attr parameter for the whole range
actually makes the whole thing more handy.
>
>> XEN_GUEST_HANDLE(int) errs; /* OUT Per gfn error code */
>
> I am not sure we need a pointer for the errors either. We could have a
> single integer to express the error number and the page that caused it.
>
>
>> }
>>
>>
>> Notes
>> ~~~~~
>> Since neither x86 nor arm support all the cache/share flags above, the
>> function will return an err if the one or more flags given by the caller are
>> not supported.
>>
>>
>> ********************************************************************************
>> References
>> ~~~~~~~~~~
>> [1] [RFC]Proposal to allow setting up shared memory areas between VMs
>> from xl config file
>> v2: https://lists.xen.org/archives/html/xen-devel/2017-06/msg02256.html
>> v1: https://lists.xen.org/archives/html/xen-devel/2017-05/msg01288.html
>> [2] https://lists.xen.org/archives/html/xen-devel/2017-06/msg02918.html
>> [3]
>> http://xenbits.xen.org/hg/staging/xen-unstable.hg/file/fe6c71e5586b/xen/include/public/domctl.h#l621
>> [4] Intel® 64 and IA-32 Architectures Software Developer’s Manual,
>> Volume 3, 11.3
>> [5] ARM® Architecture Reference Manual - ARMv8, for ARMv8-A
>> architecture profile(Issue B.a), B2.7.1
>>
Cheers,
Zhongze Liu.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |