Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

[Julien Grall <julien.grall@xxxxxxx>]

On 11/02/17 00:14, Volodymyr Babchuk wrote:
> Hello,
Hi Volodymyr,

> This e-mail is sort of follow-up to the two threads: [1] (my thread
> about TEE interaction) and [2] (Edgar's thread regarding handling SMC
> calls in platform_hvc). I want to discuss more broad topic there.
>
> Obviously, there are growing number of SMC users and current state of
> SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
> secure way, Xilinx wants to forward some calls directly to Secure
> Monitor, while allowing to handle other in userspace, etc.
>
> My proposition is to gather all requirements to SMC (and HVC) handling
> in one place (e.g. in this mail thread). After we' will have clear
> picture of what we want, we will be able to develop some solution,
> that will satisfy us all. At least, I hope so :)
>
> Also I want to remind, that there are ARM document called "SMC Calling
> Convention" [3]. According to it, any aarch64 hypervisor "must
> implement the Standard Secure and Hypervisor Service calls". At this
> moment XEN does not conform to this.
>
> So, lets get started with the requirements:
> 0. There are no much difference between SMC and HVC handling (at least
> according to SMCCC).
> 1. Hypervisor should at least provide own UUID and version while
> called by SMC/HVC
Do we need to reserve the UUID for Xen?

> 2. Hypervisor should forward some calls from dom0 directly to Secure
> Monitor (Xilinx use case)
> 3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
> architecture service calls, etc.
> 4. Hypervisor should handle TEE calls in a secure way (e.g. no
> untrusted handlers in Dom0 userspace).
> 5. Hypervisor should support multiple TEEs (at least at compilation time).
> 6. Hypervisor should do this as fast as possible (DRM playback use case).
> 7. All domains (including dom0) should be handled in the same way.
+1 here. Same path for all domains means less code and you it will get 
tested more
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel