[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: Thu, 6 Feb 2020 09:20:19 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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?

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




reply via email to

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