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

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



Hello,

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
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.
8. Not all domains will have right to issue certain SMCs.
9. Hypervisor will issue own SMCs in some cases.

This is high-level requirements. Feel free to expand this list.

Current SMC handling code does not even handle PSCI calls. Only HVC
trap handler have branch to handle PSCI calls. SMCs are forwarded to
VM monitor subsystem. There are even no advance_pc() call, so monitor
needs to advance PC by itself. Also, dom0 can't have monitor, so there
are no way to handle SMCs that originate from dom0. So, basically,
current code does not meet any requirements from above list. This
means that we can start from scratch and develop any solution.

But at this moment I only want to gather requirements. So feel free to
point at what I have missed.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg02220.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00635.html
[3] 
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@xxxxxxxxx

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

 


Rackspace

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