Re: [RFC v1 3/5] xen/arm: introduce SCMI-SMC mediator driver

[Julien Grall <julien@xxxxxxx>]

Hi,

On 24/12/2021 17:02, Oleksii Moisieiev wrote:
> On Fri, Dec 24, 2021 at 03:42:42PM +0100, Julien Grall wrote:
> > On 20/12/2021 16:41, Oleksii Moisieiev wrote:
> > > >     2) What are the expected memory attribute for the regions?
> > > xen uses iommu_permit_access to pass agent page to the guest. So guest can 
> > > access the page directly.
> > I think you misunderstood my comment. Memory can be mapped with various type
> > (e.g. Device, Memory) and attribute (cacheable, non-cacheable...). What will
> > the firmware expect? What will the guest OS usually?
> >
> > The reason I am asking is the attributes have to matched to avoid any
> > coherency issues. At the moment, if you use XEN_DOMCTL_memory_mapping, Xen
> > will configure the stage-2 to use Device nGnRnE. As the result, the result
> > memory access will be Device nGnRnE which is very strict.
> Let me share with you the configuration example:
> scmi expects memory to be configured in the device-tree:
>
> cpu_scp_shm: scp-shmem@0xXXXXXXX {
>         compatible = "arm,scmi-shmem";
>         reg = <0x0 0xXXXXXX 0x0 0x1000>;
> };
>
> where XXXXXX address I allocate in alloc_magic_pages function.
The goal of alloc_magic_pages() is to allocate RAM. However, what you 
want is a guest physical address and then map a part of the shared page.
I can see two options here:
  1) Hardcode the SCMI region in the memory map
  2) Create a new region in the memory map that can be used for 
reserving memory for mapping.
We still have plenty of space in the guest memory map. So the former is 
probably going to be fine for now.
> Then I get paddr of the scmi channel for this domain and use
> XEN_DOMCTL_memory_mapping to map scmi channel address to gfn.
>  > Hope I wass able to answer your question.
What you provided me is how the guest OS will locate the shared memory. 
This still doesn't tell me which memory attribute will be used to map 
the page in Stage-1 (guest page-tables).
To find that out, you want to look at the driver and how the mapping is 
done. The Linux driver (drivers/firmware/arm_scmi) is using 
devm_ioremap() (see smc_chan_setup()).
Under the hood, the function devm_ioremap() is using PROT_DEVICE_nGnRE 
(arm64) which is one of the most restrictive memory attribute.
This means the firmware should be able to deal with the most restrictive 
attribute and therefore using XEN_DOMCTL_memory_mapping to map the 
shared page in stage-2 should be fine.
Cheers,

--
Julien Grall