| Message ID | 20190611184541.7281-10-volodymyr_babchuk@epam.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | TEE mediator (and OP-TEE) support in XEN | expand |
Hi Volodymyr, On 6/11/19 7:46 PM, Volodymyr Babchuk wrote: > This enumeration controls TEE type for a domain. Currently there is > two possible options: either 'none' or 'optee'. > > 'none' is the default value and it basically disables TEE support at > all. > > 'optee' enables access to the OP-TEE running on a host machine. This > requires special OP-TEE build with virtualization support enabled. > > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > > --- > All the patches to optee.c should be merged together. They were > split to ease up review. But they depend heavily on each other. > > Changes from v5: > - Replaced "native" with "optee" in the commit description. > - Updated and extended documentation based on Julien Grall's > and Ian Jackson's suggestions. > > Changes from v4: > - "native" option was replaced with "optee" > - "tee" property was moved from arch-specific section to the > global one. Documentation moved inside "Devices" section. > > Changes from v3: > - tee_enabled renamed to tee_type. Currently two types are supported > as described in the commit message > - Add LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE definition > > Changes from v2: > - Use arch.tee_enabled instead of separate domctl > --- > docs/man/xl.cfg.5.pod.in | 21 +++++++++++++++++++++ > tools/libxl/libxl.h | 5 +++++ > tools/libxl/libxl_arm.c | 13 +++++++++++++ > tools/libxl/libxl_types.idl | 6 ++++++ > tools/xl/xl_parse.c | 9 +++++++++ > 5 files changed, 54 insertions(+) > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index c99d40307e..e65ab6111f 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -1544,6 +1544,27 @@ Set maximum height for pointer device. > > =back > > +=item B<tee="STRING"> > + > +B<Arm only.> Set TEE type for the guest. TEE is a Trusted Execution > +Environment -- separate secure OS found on some platforms. B<STRING> can be one of the: > + > +=over 4 > + > +=item B<none> > + > +Disable TEE support at all. This is the default value. How about "Don't allow the guest to use TEE if present on the platform. This is the default value.". > + > +=item B<optee> > + > +Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE > +is required for this. If this option is selected, guest will be able OOI, what happen if OP-TEE does not support virtualization. Will Xen forbid to use it? > +to access to the real OP-TEE OS running on the host. Guest creation s/real// it is redundant with the rest of the sentence. However, it does not really answer to the question regarding isolation. > +will fail if OP-TEE have no resources for a new guest. Number of supported > +guests depends on OP-TEE configuration. How about the following description (correct me if my understanding is wrong): "Allow a guest to access the host OP-TEE OS. Xen will mediate the access to OP-TEE and the resource isolation will be provided directly by OP-TEE. OP-TEE itself may limit the number of guests that can concurrently use it. This requires a virtualization-aware OP-TEE for this to work. This feature is a B<technology preview>." How can a user know whether OP-TEE supports virtualization? Is it configurable at build? Cheers,
Hi Julien, Julien Grall writes: > Hi Volodymyr, > > On 6/11/19 7:46 PM, Volodymyr Babchuk wrote: >> This enumeration controls TEE type for a domain. Currently there is >> two possible options: either 'none' or 'optee'. >> >> 'none' is the default value and it basically disables TEE support at >> all. >> >> 'optee' enables access to the OP-TEE running on a host machine. This >> requires special OP-TEE build with virtualization support enabled. >> >> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> >> >> --- >> All the patches to optee.c should be merged together. They were >> split to ease up review. But they depend heavily on each other. >> >> Changes from v5: >> - Replaced "native" with "optee" in the commit description. >> - Updated and extended documentation based on Julien Grall's >> and Ian Jackson's suggestions. >> >> Changes from v4: >> - "native" option was replaced with "optee" >> - "tee" property was moved from arch-specific section to the >> global one. Documentation moved inside "Devices" section. >> >> Changes from v3: >> - tee_enabled renamed to tee_type. Currently two types are supported >> as described in the commit message >> - Add LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE definition >> >> Changes from v2: >> - Use arch.tee_enabled instead of separate domctl >> --- >> docs/man/xl.cfg.5.pod.in | 21 +++++++++++++++++++++ >> tools/libxl/libxl.h | 5 +++++ >> tools/libxl/libxl_arm.c | 13 +++++++++++++ >> tools/libxl/libxl_types.idl | 6 ++++++ >> tools/xl/xl_parse.c | 9 +++++++++ >> 5 files changed, 54 insertions(+) >> >> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in >> index c99d40307e..e65ab6111f 100644 >> --- a/docs/man/xl.cfg.5.pod.in >> +++ b/docs/man/xl.cfg.5.pod.in >> @@ -1544,6 +1544,27 @@ Set maximum height for pointer device. >> =back >> +=item B<tee="STRING"> >> + >> +B<Arm only.> Set TEE type for the guest. TEE is a Trusted Execution >> +Environment -- separate secure OS found on some platforms. B<STRING> can be one of the: >> + >> +=over 4 >> + >> +=item B<none> >> + >> +Disable TEE support at all. This is the default value. > How about "Don't allow the guest to use TEE if present on the > platform. This is the default value.". I'm perfectly fine with this. >> + >> +=item B<optee> >> + >> +Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE >> +is required for this. If this option is selected, guest will be able > > OOI, what happen if OP-TEE does not support virtualization. Will Xen > forbid to use it? Yes, Xen will get an error from OP-TEE during domain construction. This will lead to domain creation failure. >> +to access to the real OP-TEE OS running on the host. Guest creation > > s/real// it is redundant with the rest of the sentence. However, it > does not really answer to the question regarding isolation. Your assumption is correct - OP-TEE provides isolation on its side. > >> +will fail if OP-TEE have no resources for a new guest. Number of supported >> +guests depends on OP-TEE configuration. > > How about the following description (correct me if my understanding is > wrong): > > "Allow a guest to access the host OP-TEE OS. Xen will mediate the > access to OP-TEE and the resource isolation will be provided directly > by OP-TEE. OP-TEE itself may limit the number of guests that can > concurrently use it. This requires a virtualization-aware OP-TEE for > this to work. > > This feature is a B<technology preview>." That's much better than my version. Thank you. > How can a user know whether OP-TEE supports virtualization? Is it > configurable at build? Yes, there is a special configuration option CFG_VIRTUALIZATION. This is covered in OP-TEE documentation at [1] [1] https://optee.readthedocs.io/architecture/virtualization.html
On 18/06/2019 12:19, Volodymyr Babchuk wrote: > > Hi Julien, Hi, > > Julien Grall writes: >>> + >>> +=item B<optee> >>> + >>> +Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE >>> +is required for this. If this option is selected, guest will be able >> >> OOI, what happen if OP-TEE does not support virtualization. Will Xen >> forbid to use it? > Yes, Xen will get an error from OP-TEE during domain construction. This > will lead to domain creation failure. This is a bit odd. It means we have no way to know in advance whether OP-TEE will be able to create a client. In other word, when the mediator is built in Xen, all existing setup with OP-TEE (and no-virtualization) will fail. My expectation is Xen should be able to know whether the mediator can be used. > >>> +to access to the real OP-TEE OS running on the host. Guest creation >> >> s/real// it is redundant with the rest of the sentence. However, it >> does not really answer to the question regarding isolation. > Your assumption is correct - OP-TEE provides isolation on its side. > >> >>> +will fail if OP-TEE have no resources for a new guest. Number of supported >>> +guests depends on OP-TEE configuration. >> >> How about the following description (correct me if my understanding is >> wrong): >> >> "Allow a guest to access the host OP-TEE OS. Xen will mediate the >> access to OP-TEE and the resource isolation will be provided directly >> by OP-TEE. OP-TEE itself may limit the number of guests that can >> concurrently use it. This requires a virtualization-aware OP-TEE for >> this to work. >> >> This feature is a B<technology preview>." > That's much better than my version. Thank you. > >> How can a user know whether OP-TEE supports virtualization? Is it >> configurable at build? > Yes, there is a special configuration option CFG_VIRTUALIZATION. This is > covered in OP-TEE documentation at [1] > > [1] https://optee.readthedocs.io/architecture/virtualization.html Do we expect the link to be stable? If so, then I think a link in the documentation would be useful. Cheers,
Julien Grall writes: > On 18/06/2019 12:19, Volodymyr Babchuk wrote: >> >> Hi Julien, > > Hi, > >> >> Julien Grall writes: >>>> + >>>> +=item B<optee> >>>> + >>>> +Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE >>>> +is required for this. If this option is selected, guest will be able >>> >>> OOI, what happen if OP-TEE does not support virtualization. Will Xen >>> forbid to use it? >> Yes, Xen will get an error from OP-TEE during domain construction. This >> will lead to domain creation failure. > > This is a bit odd. It means we have no way to know in advance whether > OP-TEE will be able to create a client. Yes. There can be at least two reasons for this: 1. OP-TEE is built without virtualization support at all 2. OP-TEE have no resources for a new guest > In other word, when the > mediator is built in Xen, all existing setup with OP-TEE (and > no-virtualization) will fail. Right. If user provides DTB with 'optee' node, but OP-TEE is build without virtualization support, Dom0 will not be created. This can be fixed by adding new capability flag into OP-TEE, that tells Xen about virtualization support. For some reason I missed this when I implemented VM support in OP-TEE :( > My expectation is Xen should be able to know whether the mediator can be used. I need to implement additional capability flag in the OP-TEE. This is not so hard, but it will be available only in the next release. For now, we can document this limitation somewhere. >> >>>> +to access to the real OP-TEE OS running on the host. Guest creation >>> >>> s/real// it is redundant with the rest of the sentence. However, it >>> does not really answer to the question regarding isolation. >> Your assumption is correct - OP-TEE provides isolation on its side. >> >>> >>>> +will fail if OP-TEE have no resources for a new guest. Number of supported >>>> +guests depends on OP-TEE configuration. >>> >>> How about the following description (correct me if my understanding is >>> wrong): >>> >>> "Allow a guest to access the host OP-TEE OS. Xen will mediate the >>> access to OP-TEE and the resource isolation will be provided directly >>> by OP-TEE. OP-TEE itself may limit the number of guests that can >>> concurrently use it. This requires a virtualization-aware OP-TEE for >>> this to work. >>> >>> This feature is a B<technology preview>." >> That's much better than my version. Thank you. >> >>> How can a user know whether OP-TEE supports virtualization? Is it >>> configurable at build? >> Yes, there is a special configuration option CFG_VIRTUALIZATION. This is >> covered in OP-TEE documentation at [1] >> >> [1] https://optee.readthedocs.io/architecture/virtualization.html > > Do we expect the link to be stable? If so, then I think a link in the > documentation would be useful. This is the official OP-TEE documentation. So, yes, it should be stable. I can put this link into the code somewhere.
On 6/18/19 3:30 PM, Volodymyr Babchuk wrote: > > > Julien Grall writes: > >> On 18/06/2019 12:19, Volodymyr Babchuk wrote: >>> >>> Hi Julien, >> >> Hi, >> >>> >>> Julien Grall writes: >>>>> + >>>>> +=item B<optee> >>>>> + >>>>> +Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE >>>>> +is required for this. If this option is selected, guest will be able >>>> >>>> OOI, what happen if OP-TEE does not support virtualization. Will Xen >>>> forbid to use it? >>> Yes, Xen will get an error from OP-TEE during domain construction. This >>> will lead to domain creation failure. >> >> This is a bit odd. It means we have no way to know in advance whether >> OP-TEE will be able to create a client. > Yes. There can be at least two reasons for this: > 1. OP-TEE is built without virtualization support at all > 2. OP-TEE have no resources for a new guest > >> In other word, when the >> mediator is built in Xen, all existing setup with OP-TEE (and >> no-virtualization) will fail. > Right. If user provides DTB with 'optee' node, but OP-TEE is build without > virtualization support, Dom0 will not be created. This can be fixed by > adding new capability flag into OP-TEE, that tells Xen about > virtualization support. For some reason I missed this when I implemented > VM support in OP-TEE :( > >> My expectation is Xen should be able to know whether the mediator can be used. > I need to implement additional capability flag in the OP-TEE. This is > not so hard, but it will be available only in the next release. For now, > we can document this limitation somewhere. Is OP-TEE already released with virtualization? If not, when will it be? > >>> >>>>> +to access to the real OP-TEE OS running on the host. Guest creation >>>> >>>> s/real// it is redundant with the rest of the sentence. However, it >>>> does not really answer to the question regarding isolation. >>> Your assumption is correct - OP-TEE provides isolation on its side. >>> >>>> >>>>> +will fail if OP-TEE have no resources for a new guest. Number of supported >>>>> +guests depends on OP-TEE configuration. >>>> >>>> How about the following description (correct me if my understanding is >>>> wrong): >>>> >>>> "Allow a guest to access the host OP-TEE OS. Xen will mediate the >>>> access to OP-TEE and the resource isolation will be provided directly >>>> by OP-TEE. OP-TEE itself may limit the number of guests that can >>>> concurrently use it. This requires a virtualization-aware OP-TEE for >>>> this to work. >>>> >>>> This feature is a B<technology preview>." >>> That's much better than my version. Thank you. >>> >>>> How can a user know whether OP-TEE supports virtualization? Is it >>>> configurable at build? >>> Yes, there is a special configuration option CFG_VIRTUALIZATION. This is >>> covered in OP-TEE documentation at [1] >>> >>> [1] https://optee.readthedocs.io/architecture/virtualization.html >> >> Do we expect the link to be stable? If so, then I think a link in the >> documentation would be useful. > This is the official OP-TEE documentation. So, yes, it should be stable. > I can put this link into the code somewhere. I would add the link in the xl documentation and also in the commit message of patch #2. I can do the later on commit. Cheers,
Julien Grall writes: > On 6/18/19 3:30 PM, Volodymyr Babchuk wrote: >> >> >> Julien Grall writes: >> >>> On 18/06/2019 12:19, Volodymyr Babchuk wrote: >>>> >>>> Hi Julien, >>> >>> Hi, >>> >>>> >>>> Julien Grall writes: >>>>>> + >>>>>> +=item B<optee> >>>>>> + >>>>>> +Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE >>>>>> +is required for this. If this option is selected, guest will be able >>>>> >>>>> OOI, what happen if OP-TEE does not support virtualization. Will Xen >>>>> forbid to use it? >>>> Yes, Xen will get an error from OP-TEE during domain construction. This >>>> will lead to domain creation failure. >>> >>> This is a bit odd. It means we have no way to know in advance whether >>> OP-TEE will be able to create a client. >> Yes. There can be at least two reasons for this: >> 1. OP-TEE is built without virtualization support at all >> 2. OP-TEE have no resources for a new guest >> >>> In other word, when the >>> mediator is built in Xen, all existing setup with OP-TEE (and >>> no-virtualization) will fail. >> Right. If user provides DTB with 'optee' node, but OP-TEE is build without >> virtualization support, Dom0 will not be created. This can be fixed by >> adding new capability flag into OP-TEE, that tells Xen about >> virtualization support. For some reason I missed this when I implemented >> VM support in OP-TEE :( >> >>> My expectation is Xen should be able to know whether the mediator can be used. >> I need to implement additional capability flag in the OP-TEE. This is >> not so hard, but it will be available only in the next release. For now, >> we can document this limitation somewhere. > > Is OP-TEE already released with virtualization? If not, when will it be? Yes, OP-TEE 3.5.0 was released on 26 April 2019 and it includes virtualization support. >> >>>> >>>>>> +to access to the real OP-TEE OS running on the host. Guest creation >>>>> >>>>> s/real// it is redundant with the rest of the sentence. However, it >>>>> does not really answer to the question regarding isolation. >>>> Your assumption is correct - OP-TEE provides isolation on its side. >>>> >>>>> >>>>>> +will fail if OP-TEE have no resources for a new guest. Number of supported >>>>>> +guests depends on OP-TEE configuration. >>>>> >>>>> How about the following description (correct me if my understanding is >>>>> wrong): >>>>> >>>>> "Allow a guest to access the host OP-TEE OS. Xen will mediate the >>>>> access to OP-TEE and the resource isolation will be provided directly >>>>> by OP-TEE. OP-TEE itself may limit the number of guests that can >>>>> concurrently use it. This requires a virtualization-aware OP-TEE for >>>>> this to work. >>>>> >>>>> This feature is a B<technology preview>." >>>> That's much better than my version. Thank you. >>>> >>>>> How can a user know whether OP-TEE supports virtualization? Is it >>>>> configurable at build? >>>> Yes, there is a special configuration option CFG_VIRTUALIZATION. This is >>>> covered in OP-TEE documentation at [1] >>>> >>>> [1] https://optee.readthedocs.io/architecture/virtualization.html >>> >>> Do we expect the link to be stable? If so, then I think a link in the >>> documentation would be useful. >> This is the official OP-TEE documentation. So, yes, it should be stable. >> I can put this link into the code somewhere. > > I would add the link in the xl documentation and also in the commit > message of patch #2. I can do the later on commit. It would be great. Thank you.
Hi, On 18/06/2019 16:23, Volodymyr Babchuk wrote: > > Julien Grall writes: > >> On 6/18/19 3:30 PM, Volodymyr Babchuk wrote: >>> >>> >>> Julien Grall writes: >>> >>>> On 18/06/2019 12:19, Volodymyr Babchuk wrote: >>>>> >>>>> Hi Julien, >>>> >>>> Hi, >>>> >>>>> >>>>> Julien Grall writes: >>>>>>> + >>>>>>> +=item B<optee> >>>>>>> + >>>>>>> +Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE >>>>>>> +is required for this. If this option is selected, guest will be able >>>>>> >>>>>> OOI, what happen if OP-TEE does not support virtualization. Will Xen >>>>>> forbid to use it? >>>>> Yes, Xen will get an error from OP-TEE during domain construction. This >>>>> will lead to domain creation failure. >>>> >>>> This is a bit odd. It means we have no way to know in advance whether >>>> OP-TEE will be able to create a client. >>> Yes. There can be at least two reasons for this: >>> 1. OP-TEE is built without virtualization support at all >>> 2. OP-TEE have no resources for a new guest >>> >>>> In other word, when the >>>> mediator is built in Xen, all existing setup with OP-TEE (and >>>> no-virtualization) will fail. >>> Right. If user provides DTB with 'optee' node, but OP-TEE is build without >>> virtualization support, Dom0 will not be created. This can be fixed by >>> adding new capability flag into OP-TEE, that tells Xen about >>> virtualization support. For some reason I missed this when I implemented >>> VM support in OP-TEE :( >>> >>>> My expectation is Xen should be able to know whether the mediator can be used. >>> I need to implement additional capability flag in the OP-TEE. This is >>> not so hard, but it will be available only in the next release. For now, >>> we can document this limitation somewhere. >> >> Is OP-TEE already released with virtualization? If not, when will it be? > Yes, OP-TEE 3.5.0 was released on 26 April 2019 and it includes > virtualization support. Ok. Please try to solve this problem for the next release. For now, I think there are a way to workaround the lack of a feature flag. In the detection of OP-TEE, you can try to create a client. If it fails, then it means OP-TEE does not support virtualization. This is assuming that OP-TEE will fail gracefully. Cheers,
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index c99d40307e..e65ab6111f 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -1544,6 +1544,27 @@ Set maximum height for pointer device. =back +=item B<tee="STRING"> + +B<Arm only.> Set TEE type for the guest. TEE is a Trusted Execution +Environment -- separate secure OS found on some platforms. B<STRING> can be one of the: + +=over 4 + +=item B<none> + +Disable TEE support at all. This is the default value. + +=item B<optee> + +Allow a guest to use OP-TEE. Note that a virtualization-aware OP-TEE +is required for this. If this option is selected, guest will be able +to access to the real OP-TEE OS running on the host. Guest creation +will fail if OP-TEE have no resources for a new guest. Number of supported +guests depends on OP-TEE configuration. + +=back + =back =head2 Paravirtualised (PV) Guest Specific Options diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 9bacfb97f0..1fe6ea2bd8 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -273,6 +273,11 @@ */ #define LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION 1 +/* + * libxl_domain_build_info has the arch_arm.tee field. + */ +#define LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE 1 + /* * LIBXL_HAVE_SOFT_RESET indicates that libxl supports performing * 'soft reset' for domains and there is 'soft_reset' shutdown reason diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c index 141e159043..6b72c00960 100644 --- a/tools/libxl/libxl_arm.c +++ b/tools/libxl/libxl_arm.c @@ -89,6 +89,19 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, return ERROR_FAIL; } + switch (d_config->b_info.tee) { + case LIBXL_TEE_TYPE_NONE: + config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NONE; + break; + case LIBXL_TEE_TYPE_OPTEE: + config->arch.tee_type = XEN_DOMCTL_CONFIG_TEE_OPTEE; + break; + default: + LOG(ERROR, "Unknown TEE type %d", + d_config->b_info.tee); + return ERROR_FAIL; + } + return 0; } diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index b61399ce36..fa5ee65463 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -460,6 +460,11 @@ libxl_gic_version = Enumeration("gic_version", [ (0x30, "v3") ], init_val = "LIBXL_GIC_VERSION_DEFAULT") +libxl_tee_type = Enumeration("tee_type", [ + (0, "none"), + (1, "optee") + ], init_val = "LIBXL_TEE_TYPE_NONE") + libxl_rdm_reserve = Struct("rdm_reserve", [ ("strategy", libxl_rdm_reserve_strategy), ("policy", libxl_rdm_reserve_policy), @@ -537,6 +542,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("nested_hvm", libxl_defbool), ("apic", libxl_defbool), ("dm_restrict", libxl_defbool), + ("tee", libxl_tee_type), ("u", KeyedUnion(None, libxl_domain_type, "type", [("hvm", Struct(None, [("firmware", string), ("bios", libxl_bios_type), diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index e105bda2bb..0604374ef3 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -2691,6 +2691,15 @@ skip_usbdev: } } + if (!xlu_cfg_get_string (config, "tee", &buf, 1)) { + e = libxl_tee_type_from_string(buf, &b_info->tee); + if (e) { + fprintf(stderr, + "Unknown tee \"%s\" specified\n", buf); + exit(-ERROR_FAIL); + } + } + parse_vkb_list(config, d_config); xlu_cfg_destroy(config);
This enumeration controls TEE type for a domain. Currently there is two possible options: either 'none' or 'optee'. 'none' is the default value and it basically disables TEE support at all. 'optee' enables access to the OP-TEE running on a host machine. This requires special OP-TEE build with virtualization support enabled. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> --- All the patches to optee.c should be merged together. They were split to ease up review. But they depend heavily on each other. Changes from v5: - Replaced "native" with "optee" in the commit description. - Updated and extended documentation based on Julien Grall's and Ian Jackson's suggestions. Changes from v4: - "native" option was replaced with "optee" - "tee" property was moved from arch-specific section to the global one. Documentation moved inside "Devices" section. Changes from v3: - tee_enabled renamed to tee_type. Currently two types are supported as described in the commit message - Add LIBXL_HAVE_BUILDINFO_ARCH_ARM_TEE definition Changes from v2: - Use arch.tee_enabled instead of separate domctl --- docs/man/xl.cfg.5.pod.in | 21 +++++++++++++++++++++ tools/libxl/libxl.h | 5 +++++ tools/libxl/libxl_arm.c | 13 +++++++++++++ tools/libxl/libxl_types.idl | 6 ++++++ tools/xl/xl_parse.c | 9 +++++++++ 5 files changed, 54 insertions(+)