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

From: Marc Zyngier <maz@kernel.org>
To: Heyi Guo <guoheyi@huawei.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Gavin Shan <gshan@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Shannon Zhao <shannon.zhaosl@gmail.com>,
	Igor Mammedov <imammedo@redhat.com>,
	qemu-arm <qemu-arm@nongnu.org>, James Morse <james.morse@arm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	wanghaibin.wang@huawei.com, Dave Martin <Dave.Martin@arm.com>
Subject: Re: [RFC v2 00/14] Add SDEI support for arm64
Date: Thu, 06 Feb 2020 17:30:23 +0000	[thread overview]
Message-ID: <f8394aafb2adb513186cd2784a1cb077@kernel.org> (raw)
In-Reply-To: <c67c1563-045f-a5f8-8b8b-97d792aa1912@huawei.com>

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.

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.

         M.
-- 
Jazz is not dead. It just smells funny...