[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v7 16/20] xen/arm: ffa: add defines for sharing memory



Hi Bertrand,

On Fri, Mar 3, 2023 at 2:38 PM Bertrand Marquis
<Bertrand.Marquis@xxxxxxx> wrote:
>
> Hi Jens,
>
> > On 22 Feb 2023, at 16:33, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
> >
> > Adds defines needed for sharing using the function FFA_MEM_SHARE and
> > friends.
> >
> > Signed-off-by: Jens Wiklander <jens.wiklander@xxxxxxxxxx>
> > ---
> > xen/arch/arm/tee/ffa.c | 57 ++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 57 insertions(+)
> >
> > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> > index 3571817c0bcd..bfd378f7fcd7 100644
> > --- a/xen/arch/arm/tee/ffa.c
> > +++ b/xen/arch/arm/tee/ffa.c
> > @@ -22,6 +22,14 @@
> > #include <asm/tee/ffa.h>
> > #include <asm/regs.h>
> >
> > +/*
> > + * References:
> > + * FF-A-1.0-REL: FF-A specification version 1.0 available at
> > + *               https://developer.arm.com/documentation/den0077/a
> > + * FF-A-1.1-REL0: FF-A specification version 1.1 available at
> > + *                https://developer.arm.com/documentation/den0077/e
> > + */
>
> This could actually be directly in the file header.

OK, I'll move it.

>
> > +
> > /* Error codes */
> > #define FFA_RET_OK                      0
> > #define FFA_RET_NOT_SUPPORTED           -1
> > @@ -66,6 +74,55 @@
> >  */
> > #define FFA_PAGE_SIZE                   SZ_4K
> >
> > +/*
> > + * Limit for shared buffer size. Please note that this define limits
> > + * number of pages. But user buffer can be not aligned to a page
> > + * boundary. So it is possible that user would not be able to share
> > + * exactly FFA_MAX_SHM_BUFFER_PG * FFA_PAGE_SIZE bytes.
> > + *
> > + * FF-A doesn't have any direct requirments on GlobalPlatform or vice
> > + * versa, but an implementation can very well use FF-A in order to provide
> > + * a GlobalPlatform interface on top.
> > + *
> > + * Global Platform specification for TEE requires that any TEE
> > + * implementation should allow to share buffers with size of at least
> > + * 512KB. Due to align issue mentioned above, we need to increase this
> > + * value with one.
>
> Could you give a bit more details here: what spec version, where in the spec ?
>
> I did download one version of it and at a first glance could not find this 
> value.

https://globalplatform.org/specs-library/tee-client-api-specification/
TEE Client API Specification version 1.0c, page 24, Table 4-1: API
Configuration Constants, look for TEEC_CONFIG_SHAREDMEM_MAX_SIZE. I'll
add a reference.

>
> > + */
> > +#define FFA_MAX_SHM_PAGE_COUNT          (SZ_512K / FFA_PAGE_SIZE + 1)
> > +
> > +/*
> > + * Limits the number of shared buffers that guest can have at once. This
> > + * is to prevent case, when guests tricks XEN into exhausting its own
> > + * memory by allocating many small buffers. This value has been chosen
> > + * arbitrary.
> > + */
> > +#define FFA_MAX_SHM_COUNT               32
>
> For those 2 limits, I am a bit wondering which should be defined in the code 
> or maybe
> configurable in kconfig or through xen command line or per guest.

Per guest sounds like an interesting option when these values aren't
good enough.

>
> I do not think we can answer that now but if one of these limits is reached 
> we should
> have a clear error message so that we could easily say what to modify and 
> decide
> if/how to solve it.

I'll add prints in the later patches.

>
>
> > +
> > +/* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
> > +#define FFA_HANDLE_HYP_FLAG             BIT(63, ULL)
> > +#define FFA_HANDLE_INVALID              0xffffffffffffffffULL
> > +
> > +/*
> > + * The bits for FFA_NORMAL_MEM_REG_ATTR FFA_MEM_ACC_RW below are
> > + * defined in FF-A-1.1-REL0 Table 10.18 at page 175.
> > + */
> > + /* Memory attributes: Normal memory, Write-Back cacheable, Inner 
> > shareable */
> > +#define FFA_NORMAL_MEM_REG_ATTR         0x2fU
> > +/* Memory access permissions: Read-write */
> > +#define FFA_MEM_ACC_RW                  0x2U
>
> RW bits are defined in table 10.15 at page 168 if i am not mistaking

Thanks, I'll update it.

>
> > +
> > +/* FF-A-1.1-REL0 section 10.11.4 Flags usage, page 184-187 */
> > +/* Clear memory before mapping in receiver */
> > +#define FFA_MEMORY_REGION_FLAG_CLEAR            BIT(0, U)
> > +/* Relayer may time slice this operation */
> > +#define FFA_MEMORY_REGION_FLAG_TIME_SLICE       BIT(1, U)
> > +/* Clear memory after receiver relinquishes it */
> > +#define FFA_MEMORY_REGION_FLAG_CLEAR_RELINQUISH BIT(2, U)
> > +/* Share memory transaction */
> > +#define FFA_MEMORY_REGION_TRANSACTION_TYPE_SHARE (1U << 3)
> > +
> > +
> Please only add one empty line here.

OK, I'll fix.

>
> I checked the definitions and they are all coherent with the spec.

Thanks,
Jens

>
> Cheers
> Bertrand
>
> > /* Framework direct request/response */
> > #define FFA_MSG_FLAG_FRAMEWORK          BIT(31, U)
> > #define FFA_MSG_TYPE_MASK               0xFFU;
> > --
> > 2.34.1
> >
>



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.