Re: [RFC v2 00/14] Add SDEI support for arm64

[Heyi Guo <guoheyi@huawei.com>]

Update Marc's email address.

+cc Gavin as he is posting a RFC for ARM NMI.

Hi Marc,

Really sorry for missing to update your email address, for the initial 
topic was raised long time ago and I forgot to update the Cc list in the 
commit message of the patches.

Thanks Gavin for forwarding current discussion on ARM NMI to me.

For you said SDEI is "horrible", does it mean we'd better never 
implement SDEI in virtual world? Or do you have any advice on how to 
implement it?

Thanks,

Heyi

On 2019/12/23 16:20, Guoheyi wrote:
> Hi Peter,
>
> Really appreciate your comments.
>
> For other platforms/boards emulated in qemu, like omap, imx*, etc, are 
> they just TCG platforms? Can we just enable security and EL3 emulation 
> for these platforms instead of implementing copies of firmware 
> interfaces in qemu? Also I think it is possible to optimize the code 
> to support all KVM enabled virtual boards with one single copy of SDEI 
> code, so at least the duplication of code inside qemu might be avoided.
>
> I can understand your concerns; the exsiting SDEI code in ARM Trusted 
> Firmware also tempted me when I started to writing the code in qemu. I 
> agree the ideal way is to use the existing firmware directly, but how 
> can we achieve that? Either I don't think it is good to modify the 
> firmware code too much, for firmware should be kept simple and reliable.
>
> Does James or Marc have any idea?
>
> Thanks,
>
> Heyi
>
> 在 2019/12/20 21:44, Peter Maydell 写道:
>> On Tue, 5 Nov 2019 at 09:12, Heyi Guo <guoheyi@huawei.com> wrote:
>>> SDEI is for ARM "Software Delegated Exception Interface". AS ARM64 
>>> doesn't have
>>> native non-maskable interrupt (NMI), we rely on higher privileged 
>>> (larger
>>> exception level) software to change the execution flow of lower 
>>> privileged
>>> (smaller exception level) software when certain events occur, to 
>>> emulate NMI
>>> mechanism, and SDEI is the standard interfaces between the two 
>>> levels of
>>> privileged software. It is based on SMC/HVC calls.
>>>
>>> The higher privileged software implements an SDEI dispatcher to 
>>> handle SDEI
>>> related SMC/HVC calls and trigger SDEI events; the lower privileged 
>>> software
>>> implements an SDEI client to request SDEI services and handle SDEI 
>>> events.
>> Hi; I read through these patches last week, but I didn't reply
>> then because although there are some aspects to the design that
>> I don't like, I don't have a clear idea of what a better approach
>> to the problems it's trying to solve would be. However I didn't
>> want to go home for the end of the year without providing at
>> least some response. So I'm going to lay out the parts I have
>> issues with and perhaps somebody else will have a good idea.
>>
>> The first part that I dislike here is that this is implementing
>> an entire ABI which in real hardware is provided by firmware. I
>> think that QEMU's design works best when QEMU provides emulation of
>> hardware or hardware-like facilities, which guest code (either
>> in the kernel, or firmware/bios running in the guest) can then
>> make use of. Once we start getting into implementing firmware
>> interfaces directly in QEMU this rapidly becomes a large amount
>> of work and code, and it's unclear where it should stop. Should
>> we implement also the equivalent of firmware for omap boards?
>> For imx* boards? For the raspberry pi? For xilinx boards?
>> Are we going to end up reimplementing more of ARM Trusted Firmware
>> functionality inside QEMU? The code to implement firmware-equivalent
>> ABIs in all these boards would I think quickly become a large part
>> of the codebase.
>>
>> My second concern is that to do the things it wants to do,
>> the implementation here does some pretty invasive things:
>>   * intercepting interrupt lines which ought to just be
>>     emulated hardware signals between devices and the GIC
>>   * capturing register values of other CPUs, and arbitrarily
>>     stopping those other CPUs and making them run other code
>>     at a later point in time
>> I'm really uncomfortable with what's just an 'emulated firmware'
>> interface for one specific board model doing this kind of thing.
>>
>> Finally, the stated rationale for the patchset ("we'd like an
>> emulated NMI equivalent") doesn't really feel to me like it's
>> strong enough to counterbalance the amount of code here and
>> the degree to which it's moving us into a swamp I'd prefer
>> it if we could stay out of.
>>
>> I'd be much happier with a design where QEMU provides simple
>> facilities to the guest and the guest firmware and kernel
>> deal with making use of them. I appreciate that it's not
>> clear how that would work though, given that in real hardware
>> this works by the firmware running at EL3 and KVM not
>> providing a mechanism that allows guest code that runs at
>> a higher (effective or emulated) privilege level than the
>> guest kernel...
>>
>> thanks
>> -- PMM
>>
>> .