[Top][All Lists]

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

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

From: Heyi Guo
Subject: Re: [RFC v2 00/14] Add SDEI support for arm64
Date: Tue, 4 Feb 2020 16:26:20 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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?



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?



在 2019/12/20 21:44, Peter Maydell 写道:
On Tue, 5 Nov 2019 at 09:12, Heyi Guo <address@hidden> 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...

-- PMM


reply via email to

[Prev in Thread] Current Thread [Next in Thread]