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

Re: [RFC PATCH v2] arm: dom0less: add TEE support


  • To: Julien Grall <julien@xxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Tue, 4 Jun 2024 11:56:29 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EoN9sTZzTcVWUtCrs7tmGwoVMb12tIiwhSXzCe3yGdE=; b=F5vj9BDsu8BgZ0p3Y8OLdD2KaDjwHWKYaMeGH+i7p/Rf937BjZMgop0BdYcXEP9iVaqBKYrox1uZzk2ZfDf64BGAv4Zdc8WaYfSBVHKLk1XtKZ52dodZdr5hf7kumo2mTqnYJxf1SIDi8Wj+qmtWkYOTOkvti5Ybr2v9CkEXHujBWemJ01451JuU33UinjNZphe4WqrEjpVHzVXs/PLKTK4rX2QB7MLkTletiLHP457vWFIQafrqXq6mHQC20+lf7m7+skj5LoCW/Ya9Ug0fCnKoyG7RyLKK9QBOgnrTgiZY6msarIp6L9gNFdHZwbdZjMIpyNnph6WsaAhHfGm54A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cW97bfir6t/KVEW94iLNomyIbB5DJYbsRXkR4FlrevqEwmVVUnGkKV7sX83k+kY5Guxeo1z0tTrTv3syH+eFjcIhd3cgaOSsGIBzsGwter/QzLDEz33Ic4TXqmOcfKY7L/e+Le30AFsoCyFdDMfy+xzqjOkR8GV6bNpfkqcBniOVSjX7YMmwUUktz9y2Dmke3p6cR9NuZtDZh+rDWRzomPtiGSUPEEX9vn9qiLTfJp8GGQjWbAIRU2L9IA0ya1UhyMoh4VDHAcQ8/UvH5SY6rxSYzYGI88Rzx4dxylundQIr8lgjbXZ6HaQGWZdSHNUnb1aHEQNDBy4w1boe2vcbUA==
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
  • Delivery-date: Tue, 04 Jun 2024 11:57:09 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHas4LmA3+MKr53jE6Kc+pdYgdQGLG3cwAAgAAM7IA=
  • Thread-topic: [RFC PATCH v2] arm: dom0less: add TEE support

Hi Julien,

Julien Grall <julien@xxxxxxx> writes:

> Hi Volodymyr,
>
> On 31/05/2024 18:49, Volodymyr Babchuk wrote:
>> Extend TEE mediator interface with two functions :
>>   - tee_get_type_from_dts() returns TEE type based on input string
>>   - tee_make_dtb_node() creates a DTB entry for the selected
>>     TEE mediator
>> Use those new functions to parse "xen,tee" DTS property for dom0less
>> guests and enable appropriate TEE mediator.
[...]

>> +
>> +    A string property that describes what TEE mediator should be enabled
>> +    for the domain. Possible property values are:
>> +
>> +    - "none" (or missing property value)
>> +    No TEE will be available in the VM.
>> +
>> +    - "OP-TEE"
>> +    VM will have access to the OP-TEE using classic OP-TEE SMC interface.
>> +
>> +    - "FF-A"
>> +    VM will have access to a TEE using generic FF-A interface.
>
> I understand why you chose those name, but it also means we are using
> different name in XL and Dom0less. I would rather prefer if they are
> the same.
>

Well, my first idea was to introduce additional "const char *dts_name"
for a TEE mediator description. But it seems redundant. I can rename
existing mediators so their names will correspond to names used by libxl.

>> +
>> +    In the future other TEE mediators may be added, extending possible
>> +    values for this property.
>> +
>>   - xen,domain-p2m-mem-mb
>>         Optional. A 32-bit integer specifying the amount of
>> megabytes of RAM
>> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
>> index fb63ec6fd1..13fdd44eef 100644
>> --- a/xen/arch/arm/dom0less-build.c
>> +++ b/xen/arch/arm/dom0less-build.c
>> @@ -15,6 +15,7 @@
>>   #include <asm/domain_build.h>
>>   #include <asm/static-memory.h>
>>   #include <asm/static-shmem.h>
>> +#include <asm/tee/tee.h>
>>     bool __init is_dom0less_mode(void)
>>   {
>> @@ -650,6 +651,10 @@ static int __init prepare_dtb_domU(struct domain *d, 
>> struct kernel_info *kinfo)
>>       if ( ret )
>>           goto err;
>>   +    /* We are making assumption that every mediator sets
>> d->arch.tee */
>> +    if ( d->arch.tee )
>
> I think the assumption is Ok. I would consider to move this check in
> each TEE callback. IOW call tee_make_dtb_node() unconditionally.
>

Ah, okay, makes sense.

>> +        tee_make_dtb_node(kinfo->fdt);
>
> AFAICT, tee_make_dtb_node() can return an error. So please check the
> return value.
>

Yes, you are right.

>> +
>>       /*
>>        * domain_handle_dtb_bootmodule has to be called before the rest of
>>        * the device tree is generated because it depends on the value of
>> @@ -871,6 +876,7 @@ void __init create_domUs(void)
>>           unsigned int flags = 0U;
>>           uint32_t val;
>>           int rc;
>> +        const char *tee_name;
>>             if ( !dt_device_is_compatible(node, "xen,domain") )
>>               continue;
>> @@ -881,6 +887,19 @@ void __init create_domUs(void)
>>           if ( dt_find_property(node, "xen,static-mem", NULL) )
>>               flags |= CDF_staticmem;
>>   +        tee_name = dt_get_property(node, "xen,tee", NULL);
>
> In the previous version, you used dt_property_read_property_string()
> which contained some sanity check. Can you explain why you switch to
> dt_get_property()?

Because I was confused by dt_property_read_string() return values.

I made a fresh look at it and now I understand that I need to test for
-EINVAL to determine that a property is not available and I should use
a default value. All other return codes should cause panic. I'll rework
this in the next version.

-- 
WBR, Volodymyr


 


Rackspace

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