qemu-devel
[Top][All Lists]
Advanced

[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:17:56 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2


On 2020/2/7 1:30, Marc Zyngier wrote:
On 2020-02-06 01:20, Heyi Guo wrote:
Hi Marc,

On 2020/2/5 21:15, Marc Zyngier wrote:
Hi Heyi,

On 2020-02-04 08:26, Heyi Guo wrote:
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?

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.


I've another question. The origin of "virtual" SDEI requirement comes
from the lack of hard lockup detector in VM.

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.

Indeed...


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

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.

Much appreciate your explanation and advice.

Thanks,

Heyi


        M.




reply via email to

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