Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg

[Julien Grall <julien.grall@xxxxxxx>]

On 20/03/2019 15:27, Volodymyr Babchuk wrote:
> Hello Julien,
>
> Julien Grall writes:
>
> > On 07/03/2019 21:04, Volodymyr Babchuk wrote:
> > > From: Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>
> > >
> > > This enumeration controls TEE type for a domain. Currently there is
> > > two possible options: either 'none' or 'native'.
> > >
> > > 'none' is the default value and it basically disables TEE support at
> > > all.
> > >
> > > 'native' enables access to a "real" TEE installed on a platform.
> > I am aware I made that suggestion. But I think the naming is not ideal
> > between the user and the toolstack. The question is how this is going
> > to fit with the S-EL2 feature where multiple TEE can run together?
> You see, support for S-EL2 or support for multiple TEEs is a much broader
> topic. For me, naming for configuration option is the least important
> thing in this case :-)
Naming exposed to users are hard to remove. If the naming is too ambiguous, then 
we will have to introduce a new option later on. This is not very ideal, so it 
would be better if we can find something different.
> Right there is no clear vision how it will ever work. I scanned through
> SPCI spec and I already have a couple of questions. I need to study it
> harder to make serious statements, but I already see that current
> mediator framework will hardly fit into SPCI stuff. Frankly, I have
> concerns that OP-TEE (or any other existing TEE) will be compatible
> with SPCI-enabled systems without major rework. So, we will need to do
> big overhaul anyways, when there will appear first SPCI-compatible TEEs and
> secure hypervisors.
>
> AFAIK, there is no ARMv8.4 platforms, no S-EL2 hypervisors and so on. It
> will take at least couple of years before S-EL2 will hit the market. So
> in my opinion it is too early to make any assumptions on how to support
> all this in Xen. Lets stick to the current matters.
I am fully aware that more work will need to be done with S-EL2. I am not 
expecting you (or anyone else here) to come with the implementation now. My 
point is the naming should be chosen so it prevents ambiguity with whatever we 
know will come up in the future.
> I'm not insisting on "native". But I can't invent something better right
> now. Probably, SPCI-enabled TEE also will be considered "native" as
> opposed to, say, "emulated". >
> As I said, I can't come with anything better than "native". But I'm open
> to any suggestions.
Well one solution is to ditch "native" and name it "optee". By giving the name 
you avoid ambiguity. If we ever have multiple op-tee instance running, then it 
could easily be extend with a comma. So you allow backward compatibility.
> > AFAICT, TEE also exists on other architecture. So I am wondering
> > whether this field should be moved out of arch_arm?
> In v3 thread you asked if I see any use for x86. Because in that version
> this option was in common section. Honestly, I don't see any use there,
> because I have no idea how this can be implemented on x86. 
On the v3, I pointed out that the documentation was in Arm section but the code 
was in common. When I asked a question, it does not mean I am not happy with it. 
It only means I am trying to understand your choice so I can make my mind on it. 
Sadly, you left it unanswered until now.
In this context, I am not asking you how this is going to be implemented but 
whether this option could potentially be used in the future for other 
architecture (e.g x86, RISC-V...). For instance, the option "device_tree" is 
part for common options despite it is only implemented on Arm.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel