Re: [RFC v3]Proposal to allow setting up shared memory areas between VMs from xl config file

[Julien Grall <julien.grall@arm.com>]

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@lists.xen.org
https://lists.xen.org/xen-devel