Re: [Xen-devel] [RFC v4]Proposal to allow setting up shared memory areas between VMs from xl config file

["Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxxx>]

On Wed, Aug 02, 2017 at 07:10:25PM +0100, Julien Grall wrote:
> Hi,
> 
> On 01/08/17 00:53, Stefano Stabellini wrote:
> >On Mon, 31 Jul 2017, Edgar E. Iglesias wrote:
> >>>>>  @role                 Can only be 'master' or 'slave', it defaults to 
> >>>>> 'slave'.
> >>>>>
> >>>>>  @prot                 When @role = master, this means the largest set 
> >>>>> of
> >>>>>                        stage-2 permission flags that can be granted to 
> >>>>> the
> >>>>>                        slave domains.
> >>>>>When @role = slave, this means the stage-2 permission
> >>>>>                        flags of the shared memory area.
> >>>>>                        Currently only 'rw' is supported. If not set. it
> >>>>>                        defaults to 'rw'.
> >>>>>
> >>>>>  @cache_policy         The stage-2 cacheability/shareability attributes 
> >>>>> of the
> >>>>>                        shared memory area. Currently, only two policies 
> >>>>> are
> >>>>>                        supported:
> >>>>>                          * ARM_normal: Only applicable to ARM guests. 
> >>>>> This
> >>>>>                                        would mean Inner and Outer 
> >>>>> Write-Back
> >>>>>                                        Cacheable, and Inner Shareable.
> >>>>
> >>>>
> >>>>Is there a reason not to set this to Outer Shareable?
> >>>>Again, mainly useful when these pages get shared with devs as well.
> >>>>
> >>>>The guest can always lower it to Inner Shareable via S1 tables if needed.
> >>>
> >>>I don't think we can support memory sharing with devices in this version
> >>>of the document (see above about GSoC timelines). Normal memory is inner
> >>>shareable in Xen today, it makes sense to default to that.
> >>
> >>I thought we mapped RAM as Outer shareable to guests but you seem to be 
> >>right.
> >>I think we should be mapping all RAM as Outer Shareable and then let the
> >>guest decide what is Inner and what is Outer via it's S1 tables.
> >>Right now it would be impossible to be Coherent with a DMA device outside
> >>of the Inner domain...
> >>
> >>Perhaps we should fix that and then ARM_normal would by itself become Outer.
> >>If there's agreement I can test it and send a patch.
> >
> >Today, only device memory is mapped Outer Shareable, while normal memory
> >is mapped Inner Shareable. I am OK with changing the default in
> >mfn_to_p2m_entry to Outer Shareable for normal RAM if the change would
> >make it possible to do coherent DMA with more devices on the platform.
> >Julien?
> 
> Per Table D4-44 in ARM DDI 0487B.a, outer-shareable takes precedence on
> inner-shareable. So if the guest configures the stage-1 page table with
> outer-shareable, the resultant will be outer-shareable.

You're right, I had gotten this backwards.

Thanks,
Edgar



> 
> As I pointed out in a previous version, this option is a bit confusing
> because the value set in stage-2 does not mean this will be the resultant
> value. I would strongly recommend any user wanting to share memory between
> guests to read D4.5.4 "Combining the stage 1 and stage 2 attributes" before
> using this option. Otherwise, he/she will likely be confused and end up to
> mis-configure the attribute.
> 
> The current configuration (i.e "ARM_normal") gives the most flexibility to
> the guest in term of memory attribute but prevent non-shareable mapping.
> 
> Cheers,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel