[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 0/2] Xen FF-A mediator
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?
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |