Re: [Qemu-devel] [RFC] Add virtual SDEI support in qemu

[Guoheyi <guoheyi@huawei.com>]

Thanks for all your comments. I'm going to write a simple demo to go 
through the whole workflow first, and then adjust the policies following 
the conclusions of our discussion.

Heyi


On 2019/7/16 16:47, Dave Martin wrote:
> On Mon, Jul 15, 2019 at 03:44:46PM +0100, Mark Rutland wrote:
>> On Mon, Jul 15, 2019 at 03:26:39PM +0100, James Morse wrote:
>>> On 15/07/2019 14:48, Mark Rutland wrote:
>>>> On Mon, Jul 15, 2019 at 02:41:00PM +0100, Dave Martin wrote:
>>>>> One option (suggested to me by James Morse) would be to allow userspace
>>>>> to disable in the in-kernel PSCI implementation and provide its own
>>>>> PSCI to the guest via SMC -- in which case userspace that wants to
>>>>> implement SDEI would have to implement PSCI as well.
>>>> I think this would be the best approach, since it puts userspace in
>>>> charge of everything.
>>>>
>>>> However, this interacts poorly with FW-based mitigations that we
>>>> implement in hyp. I suspect we'd probably need a mechanism to delegate
>>>> that responsibility back to the kernel, and figure out if that has any
>>>> interaction with thigns that got punted to userspace...
>>> This has come up before:
>>> https://lore.kernel.org/r/59C139D0.3040507@arm.com
>>>
>>> I agree Qemu should opt-in to this, it needs to be a feature that is enabled.
>>>
>>> I had an early version of something like this for testing SDEI before
>>> there was firmware available. The review feedback from Christoffer was
>>> that it should include HVC and SMC, their immediates, and shouldn't be
>>> tied to SMC-CC ranges.
>>>
>>> I think this should be a catch-all as Heyi describes to deliver
>>> 'unhandled SMC/HVC' to user-space as hypercall exits. We should
>>> include the immediate in the struct.
>>>
>>> We can allow Qemu to disable the in-kernel PSCI implementation, which
>>> would let it be done in user-space via this catch-all mechanism. (PSCI
>>> in user-space has come up on another thread recently). The in-kernel
>>> PSCI needs to be default-on for backwards compatibility.
>>>
>>> As Mark points out, the piece that's left is the 'arch workaround'
>>> stuff. We always need to handle these in the kernel. I don't think
>>> these should be routed-back, they should be un-obtainable by
>>> user-space.
>> Sure; I meant that those should be handled in the kernel rather than
>> going to host userspace and back.
>>
>> I was suggesting was that userspace would opt into taking ownership of
>> all HVC calls, then explicitly opt-in to the kernel handling specific
>> (sets of) calls.
> The most logical thing to do would be to have userspace handle all
> calls, but add an ioctl to forward a call to KVM.  This puts userspace
> in charge of the SMCCC interface, with KVM handling only those things
> that userspace can't do for itself, on request.
>
> If the performance overhead is unacceptable for certain calls, we could
> have a way to delegate specific function IDs to KVM.  I suspect that
> will be the exception rather than the rule.
>
>> There are probably issues with that, but I suspect defining "all
>> undandled calls" will be problematic otherwise.
> Agreed: the set of calls not handled by KVM will mutate over time.
>
> Cheers
> ---Dave
>
> .
>