[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: Fri, 7 Feb 2020 21:45:11 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 2020/2/7 18:52, James Morse wrote:
Hi guys,

On 06/02/2020 17:30, Marc Zyngier wrote:
On 2020-02-06 01:20, Heyi Guo wrote:
On 2020/2/5 21:15, Marc Zyngier wrote:
My concern is that SDEI implies having EL3. EL3 not being virtualizable
with KVM, you end-up baking SDEI in *hardware*. Of course, this hardware
is actually software (it is QEMU), but this isn't the way it was intended.
It's not the first time we've done that (PSCI is another example), but the
logic behind SDEI looks much more invasive.
Thanks for your comments.

Thinking about them for quite a while, below is my understanding,
please correct me if I'm wrong:

So should the KVM based virtual machine be treated as one with CPUs
only having NS-EL1 and NS-EL0, ideally? And SDEI messes up this model,
isn't it?
Well, that's exactly what it is (until we have nested virt, in which case
you will be able to add NS-EL2 to the mix).

PSCI only contains some one-shot operations, so it is much less
invasive than SDEI.
Is there an established pattern for how Qemu 'gets' things that are done in 
For PSCI the kernel does it, but this obviously doesn't scale to something like 

Ideally we'd get the reference implementation (from ATF) in some form that is 
easy to use...

I've another question. The origin of "virtual" SDEI requirement comes
from the lack of hard lockup detector in VM.
(this is your use case. Its origin was just symmetry with EL3<->EL2)

Sure. But nothing guarantees that the guest is going to register a SDEI
entry point anyway.
We can have some kind of
watchdog, but how can the watchdog trigger the VM OS to panic and run
kdump, even in irq-off state?
Nothing. All the events, including SDEI, are maskable, one way or another.

Gavin's approach to inject a SError is probably OK for Linux, given that
it tends to run with PSTATE.A==0. But that's not a guarantee either (if
you take a recursive exception, SError won't be delivered).
Or get stuck in debug-state (for which we mask SError), power-management, the 
vectors or
somewhere weird, like KVM's world-switch.

If you just want to kill the OS if its sort-of-alive, there is another trick:

Synchronous exceptions can't be masked because they are caused by the 
instruction pointed
to by the ELR. You can't inject an emulated data-abort unless the ELR points to 
instruction that accesses memory, but...

synchronous external abort for instruction fetch is something that  could 
happen at any
time. If you have v8.2 you can make the severity uncontainable for extra points.

On real hardware, this would be as if this instruction missed in the i-cache, 
then got an
abort from the PoU-cache. The PoU-cache must have suffered some metadata 
corruption to
report an uncontained error. On real hardware its very likely the next 
instruction would
suffer the same fate, but linux should put up a good show of trying to panic().

Good idea. It seems to be able to cover all the possible the cases, while we only need to highlight this exception in the user document :)



The long and the short of it is that there is no way to do what you want
with absolute guarantees on the ARM architecture. It just doesn't exist.
Yes. By sort-of-alive it needs to be making some kind of progress. If the CPU 
is spinning
through the vectors (because some joker unmapped them), all bets are off.




reply via email to

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