|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 03/10] xen/arm: optee: add OP-TEE mediator skeleton
Hello Julien,
Thank you for the review.
Julien Grall writes:
>> + */
>> +
>> +#include <xen/device_tree.h>
>> +#include <xen/sched.h>
>> +
>> +#include <asm/smccc.h>
>> +#include <asm/tee/tee.h>
>> +#include <asm/tee/optee_msg.h>
>> +#include <asm/tee/optee_smc.h>
>> +
>> +#define OPTEE_ENABLED ((void*)0x1)
>
> Please don't do that. Introduce a dummy structure instead and fill it
> up when needed.
>
It will be removed in the patch #5. But probably yes, I can
create empty optee_domain structure in this patch.
>> +
>> +/* Client ID 0 is reserved for hypervisor itself */
>
> s/for/for the/
>
>> +#define OPTEE_CLIENT_ID(domain) ((domain)->domain_id + 1)
>> +
>> +static bool optee_probe(void)
>> +{
>> + struct dt_device_node *node;
>> + struct arm_smccc_res resp;
>> +
>> + /* Check for entry in dtb */
>> + node = dt_find_compatible_node(NULL, NULL, "linaro,optee-tz");
>> + if ( !node )
>> + return false;
>> +
>> + /* Check UID */
>> + arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), &resp);
>> +
>> + if ( (uint32_t)resp.a0 != OPTEE_MSG_UID_0 ||
>> + (uint32_t)resp.a1 != OPTEE_MSG_UID_1 ||
>> + (uint32_t)resp.a2 != OPTEE_MSG_UID_2 ||
>> + (uint32_t)resp.a3 != OPTEE_MSG_UID_3 )
>> + return false;
>> +
>> + return true;
>> +}
>> +
>> +static int optee_domain_init(struct domain *d)
>> +{
>> + struct arm_smccc_res resp;
>> +
>> + /*
>> + * Inform OP-TEE about a new guest.
>> + * This is a "Fast" call in terms of OP-TEE. This basically
>> + * means that it can't be preempted, because there is no
>> + * thread allocated for it in OP-TEE. It is close to atomic
>> + * context in linux kernel: E.g. no blocking calls can be issued.
>
> This does not really make sense to describe Linux here. Can't you just
> make the wording OS agnostic?
>
It was just as an example. But okay, I'll remove mention of Linux.
>> + * Also, interrupts are disabled.
>> + *
>> + * a7 should be 0, so we can't skip last 6 parameters of arm_smccc_smc()
>> + */
>> + arm_smccc_smc(OPTEE_SMC_VM_CREATED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0, 0,
>> 0,
>> + &resp);
>> + if ( resp.a0 != OPTEE_SMC_RETURN_OK )
>> + {
>> + gprintk(XENLOG_WARNING, "Unable to create OPTEE client: rc =
>> 0x%X\n",
>
> gprintk will print the current vCPU and not the domain created. This
> is not very useful to know the current domain. So it would be better
> to use:
>
> printk(XENLOG_G_WARNING, "%pd: Unable to create OPTEE client: rc ...", d);
>
Good point, thank you.
>> + (uint32_t)resp.a0);
>> +
>> + return -ENODEV;
>> + }
>> +
>> + d->arch.tee = OPTEE_ENABLED;
>> +
>> + return 0;
>> +}
>> +
>> +static void forward_call(struct cpu_user_regs *regs)
>> +{
>> + struct arm_smccc_res resp;
>> +
>> + arm_smccc_smc(get_user_reg(regs, 0),
>> + get_user_reg(regs, 1),
>> + get_user_reg(regs, 2),
>> + get_user_reg(regs, 3),
>> + get_user_reg(regs, 4),
>> + get_user_reg(regs, 5),
>> + get_user_reg(regs, 6),
>> + OPTEE_CLIENT_ID(current->domain),
>> + &resp);
>> +
>> + set_user_reg(regs, 0, resp.a0);
>> + set_user_reg(regs, 1, resp.a1);
>> + set_user_reg(regs, 2, resp.a2);
>> + set_user_reg(regs, 3, resp.a3);
>> + set_user_reg(regs, 4, 0);
>> + set_user_reg(regs, 5, 0);
>> + set_user_reg(regs, 6, 0);
>> + set_user_reg(regs, 7, 0);
>> +}
>> +
>> +static int optee_relinquish_resources(struct domain *d)
>> +{
>> + return 0;
>> +}
>> +
>> +static void optee_domain_destroy(struct domain *d)
>> +{
>> + struct arm_smccc_res resp;
>> +
>> + if ( !d->arch.tee )
>> + return;
>> +
>> + /*
>> + * Inform OP-TEE that domain is shutting down. This is
>> + * also a fast SMC call, like OPTEE_SMC_VM_CREATED, so
>> + * it is also non-preemptible.
>> + * At this time all domain VCPUs should be stopped. OP-TEE
>> + * relies on this.
>> + *
>> + * a7 should be 0, so we can't skip last 6 parameters od arm_smccc_smc()
>
> NIT: s/od/of/
>
>> + */
>> + arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, OPTEE_CLIENT_ID(d), 0, 0, 0, 0,
>> 0, 0,
>> + &resp);
>
> Your split between domain_destroy and relinquish_resources looks
> wrong. If you relinquish resources before telling OP-TEE then you are
> at risk that OP-TEE will use those resources.
>
> Instead you should first tell OP-TEE the domain is shutting down, then
> release the resources.
Both this calls are supposed to be called after all guest's VCPUs are
stopped, so OP-TEE will be not able to use any resources allocated to
the domain, because OP-TEE is schedule by the Normal World. I assume,
this is true for any other TEE.
[...]
--
Best regards,Volodymyr Babchuk
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |