Re: [PATCH 0/2] Xen FF-A mediator

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 7 Jun 2022, Stefano Stabellini wrote:
> On Tue, 7 Jun 2022, Jens Wiklander wrote:
> > Hi,
> > 
> > This patch sets add a FF-A [1] mediator modeled after the TEE mediator
> > already present in Xen. The FF-A mediator implements the subset of the FF-A
> > 1.1 specification needed to communicate with OP-TEE using FF-A as transport
> > mechanism instead of SMC/HVC as with the TEE mediator. It allows a similar
> > design in OP-TEE as with the TEE mediator where OP-TEE presents one virtual
> > partition of itself to each guest in Xen.
> > 
> > The FF-A mediator is generic in the sense it has nothing OP-TEE specific
> > except that only the subset needed for OP-TEE is implemented so far. The
> > hooks needed to inform OP-TEE that a guest is created or destroyed is part
> > of the FF-A specification.
> > 
> > It should be possible to extend the FF-A mediator to implement a larger
> > portion of the FF-A 1.1 specification without breaking with the way OP-TEE
> > is communicated with here. So it should be possible to support any TEE or
> > Secure Partition using FF-A as transport with this mediator.
> > 
> > [1] https://developer.arm.com/documentation/den0077/latest
> > 
> > Thanks,
> > Jens
> 
> Hi Jens,
> 
> Many thanks for the patches! I tried to apply them to the master branch
> but unfortunately they don't apply any longer. Could you please rebase
> them on master (or even better rebase them on staging) and resend?
> 
> Thank you!

One question without having looked at the patches in details. These
patches are necessary to mediate OS (e.g. Linux) interactions with
OPTEE. The difference between xen/arch/arm/ffa.c and
xen/arch/arm/tee/optee.c is the transport mechanism: shared mem vs. SMC.
Is that right?

If only the transport is different, would it make sense to place ffa.c
under xen/arch/arm/tee?

Without having looked at the details of the transport or the FF-A
protocol let me ask you a question. Do you think it would be possible to
share part of the implementation with xen/arch/arm/tee/optee.c? I am
asking because intuitively, if only the transport is differenti I would
have thought that some things could be common. But it doesn't look like
the current patches are reusing anything from xen/arch/arm/tee/optee.c.
Are the two protocols too different?