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

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



Hello Julien,

On 1 March 2017 at 18:09, Julien Grall <julien.grall@xxxxxxx> wrote:
> On 01/03/17 14:13, Volodymyr Babchuk 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?
>
>
> I will chat internally about it and come back to you.
>
>>>
>>>> 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.
>
>
> I am not sure to understand here. Can you detail it?

Dom0 can't have VM monitor, because it is constructed by hypervisor.
And hypervisor does not create VM monitor control structures for it.
Actually, this is right thing, because probably don't want to allow
another domain to control dom0.
Current SMC handler uses to VM monitor subsystem to handle calt. Thus,
we can't handle SMCs from Dom0 at this moment.

-- 
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®.