[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC v3]Proposal to allow setting up shared memory areas between VMs from xl config file
Hi,
On 19/07/17 19:47, Stefano Stabellini wrote:
On Wed, 19 Jul 2017, Zhongze Liu wrote:
====================================================
1. Motivation and Description
====================================================
Virtual machines use grant table hypercalls to setup a share page for
inter-VMs communications. These hypercalls are used by all PV
protocols today. However, very simple guests, such as baremetal
applications, might not have the infrastructure to handle the grant table.
This project is about setting up several shared memory areas for inter-VMs
communications directly from the VM config file.
So that the guest kernel doesn't have to have grant table support (in the
embedded space, this is not unusual) to be able to communicate with
other guests.
====================================================
2. Implementation Plan:
====================================================
======================================
2.1 Introduce a new VM config option in xl:
======================================
2.1.1 Design Goals
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The shared areas should be shareable among several (>=2) VMs, so every shared
physical memory area is assigned to a set of VMs. Therefore, a “token” or
“identifier” should be used here to uniquely identify a backing memory area.
A string no longer than 128 bytes is used here to serve the purpose.
The backing area would be taken from one domain, which we will regard
as the "master domain", and this domain should be created prior to any
other "slave domain"s. Again, we have to use some kind of tag to tell who
is the "master domain".
And the ability to specify the permissions and cacheability (and shareability
for arm HVM's) of the pages to be shared should be also given to the user.
2.2.2 Syntax and Behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following example illustrates the syntax of the proposed config entry:
In xl config file of vm1:
static_shm = [ 'id=ID1, begin=0x100000, end=0x200000, role=master,
arm_shareattr=inner, arm_inner_cacheattr=wb,
arm_outer_cacheattr=wb, x86_cacheattr=wb, prot=ro',
'id=ID2, begin=0x300000, end=0x400000, role=master,
arm_shareattr=inner, arm_inner_cacheattr=wb,
arm_outer_cacheattr=wb, x86_cacheattr=wb, prot=rw' ]
Probably not a good idea to mix x86 and arm attributes in the example :-)
Just make a couple of examples instead.
In xl config file of vm2:
static_shm = [ 'id=ID1, begin=0x500000, end=0x600000, role=slave, prot=ro' ]
In xl config file of vm3:
static_shm = [ 'id=ID2, begin=0x700000, end=0x800000, role=slave, prot=ro' ]
where:
@id can be any string that matches the regexp "[^ \t\n,]+"
and no logner than 128 characters
@begin/end can be decimals or hexidemicals of the form "0x20000".
@role can only be 'master' or 'slave'
@prot can be 'n', 'r', 'ro', 'w', 'wo', 'x', 'xo', 'rw', 'rx',
'wx' or 'rwx'. Default is 'rw'.
@arm_shareattr can be 'inner' our 'outter', this will be ignored and
a warning will be printed out to the screen if it
is specified in an x86 HVM config file.
Default is 'inner'
@arm_outer_cacheattr can be 'uc', 'wt', 'wb', 'bufferable' or 'wa', this will
be ignored and a warning will be printed out to the
screen if it is specified in an x86 HVM config file.
Default is 'inner'
@arm_inner_cacheattr can be 'uc', 'wt', 'wb', 'bufferable' or 'wa'. Default
is 'wb'.
I don't think we need both @arm_outer_cacheattr and
@arm_inner_cacheattr: a single @arm_cacheattr should suffice.
In that case, you don't want to provide shareattr as they are both tight
together. For instance what you call bufferable is non-cacheable memory
and the resultant should always be outer shareable.
Also, we need to explain what each of these values mean. Instead, I
would only say that today we only support write-back:
@arm_cacheattr Only 'wb' (write-back) is supported today.
In the code I would check that arm_cacheattr is either missing, or set
to 'wb'. Throw an error in all other cases.
@x86_cacheattr can be 'uc', 'wc', 'wt', 'wp', 'wb' or 'suc'. Default
is 'wb'.
Also here, I would write:
@x86_cacheattr Only 'wb' (write-back) is supported today.
Like you wrote later, begin and end addresses need to be multiple of 4K.
This is not true. The addresses should be a multiple of the hypervisor
page granularity.
I will not be possible to map a 4K chunk in stage-2 when the hypervisor
is using 16K or 64K page granularity.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
