Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 23 Jun 2025, Julien Grall wrote:
> Hi Stefano,
> 
> On 22/06/2025 23:15, Stefano Stabellini wrote:
> > On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
> > > On 18/06/2025 02:22, Stefano Stabellini wrote:
> > > > On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> > > > > [1]:https://git.iliana.fyi/linux/patch/?id=d5141f37c42e0b833863f157ac4cee203b2ba3d2
> > > > Keep in mind that [0] refers specifically to access to MMIO regions. I
> > > > assume that the SCMI shared buffers are on normal memory? Regarding [1],
> > > > it makes sense if Linux is trying to support shared memory over MMIO.
> > > > 
> > > > Looking at one of your replies below, I am guessing the memory buffers
> > > > are actually in normal memory but the issue is that TF-A is mapping them
> > > > as uncacheable. Is that correct?
> > > > 
> > > > In that case, I still don't understand why a simple memcpy would not be
> > > > sufficient. Can you check?
> > > > 
> > > > If yes, then for now I would just simplify it down to memcpy. When
> > > > someone adds support for an SCMI server elsewhere we could look into
> > > > adding a more sophisticated memcpy and we can look at the details at
> > > > that point in time. Specifically, I am not convinced that memcpy_toio
> > > > and memcpy_fromio would work if the SCMI server is on a separate
> > > > non-coherent microcontroller.
> > > > 
> > > According to the TF-A implementation  SCMI memory
> > > 
> > > is mapped with the  flags: MT_DEVICE (like for  stm32mp1) or
> > > MT_NON_CACHEABLE (for rpi3)
> > > 
> > > So probably you're right. I will check with simple memcpy.
> > 
> > There is a difference between MT_DEVICE and MT_NON_CACHEABLE: as far as
> > I know MT_DEVICE requires aligned accesses while MT_NON_CACHEABLE does
> > not.
> > 
> > However, as I wrote in the other email, if I am not mistaken the current
> > implementation of memcpy might work well for us anyway. (To be
> > confirmed.)
> 
> I am not entirely sure what exactly you want to confirm. I have already
> mentioned several time that our memcpy() on arm64 is using unaligned access.
> So it can't be used for copying data to/from device memory area.

I wrote it more clearly here:
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506221438250.8066@ubuntu-linux-20-04-desktop/

Assuming that the address passed to memcpy is 4K aligned, then it seems
to me that our memcpy implementation is using only aligned accesses.