[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor
Hi, Julien On 28 February 2017 at 15:51, Julien Grall <julien.grall@xxxxxxx> wrote: >> 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? Yes, I think so. But I don't know the procedure. Should be that UUID registered somewhere? > >> 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 Yep. But this is somewhat incompatible with current implementation, as currently VM monitor mechanism is being used. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk@xxxxxxxxx _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |