From: Zhongze Liu <blackskygg@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
zhongzeliu <zhongzeliu@hustunique.com>,
Jan Beulich <jbeulich@suse.com>,
xen-devel@lists.xen.org
Subject: [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes
Date: Sat, 1 Jul 2017 04:15:41 +0800 [thread overview]
Message-ID: <CAHrd_joO-DWyK=x_piKC6Pfx2LY3HDLQGMUoRF4PFoauDSSiaA@mail.gmail.com> (raw)
********************************************************************************
DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes
Zhongze Liu <blackskygg@gmail.com>
********************************************************************************
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
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
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 */
#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
/* 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)
struct xen_domctl_memattrs_op {
int op; /* IN XEN_DOMCTL_MEMATTRS_OP_* */
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(int) errs; /* OUT Per gfn error code */
}
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next reply other threads:[~2017-06-30 20:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 20:15 Zhongze Liu [this message]
2017-06-30 21:48 ` [RFC] DOMCTL_memattrs_op : a new DOMCTL to play with stage-2 page attributes Stefano Stabellini
2017-07-01 8:29 ` Zhongze Liu
2017-07-01 9:16 ` Zhongze Liu
2017-07-01 9:22 ` Zhongze Liu
2017-07-03 11:16 ` Julien Grall
2017-07-03 15:28 ` Zhongze Liu
2017-07-03 17:40 ` Stefano Stabellini
2017-07-03 14:25 ` Jan Beulich
2017-07-03 15:47 ` Zhongze Liu
2017-07-03 17:58 ` Stefano Stabellini
2017-07-04 7:47 ` Jan Beulich
2017-07-05 18:35 ` Stefano Stabellini
2017-07-05 20:39 ` Julien Grall
2017-07-06 8:36 ` Jan Beulich
2017-07-06 17:42 ` Stefano Stabellini
2017-07-06 18:07 ` Julien Grall
2017-07-07 7:27 ` Jan Beulich
2017-07-07 8:56 ` George Dunlap
2017-07-07 9:39 ` Jan Beulich
2017-07-06 8:23 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHrd_joO-DWyK=x_piKC6Pfx2LY3HDLQGMUoRF4PFoauDSSiaA@mail.gmail.com' \
--to=blackskygg@gmail.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=xen-devel@lists.xenproject.org \
--cc=zhongzeliu@hustunique.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).