Re: [PATCH v9 07/11] hvf: arm: Implement PSCI handling

[Marc Zyngier]

On Wed, 15 Sep 2021 11:58:29 +0100,
Alexander Graf <agraf@csgraf.de> wrote:
> 
> 
> On 15.09.21 11:46, Marc Zyngier wrote:
> > On Mon, 13 Sep 2021 13:30:57 +0100,
> > Peter Maydell <peter.maydell@linaro.org> wrote:
> >> On Mon, 13 Sept 2021 at 13:02, Alexander Graf <agraf@csgraf.de> wrote:
> >>>
> >>> On 13.09.21 13:44, Peter Maydell wrote:
> >>>> On Mon, 13 Sept 2021 at 12:07, Alexander Graf <agraf@csgraf.de> wrote:
> >>>>> To keep your train of thought though, what would you do if we encounter
> >>>>> a conduit that is different from the chosen one? Today, I am aware of 2
> >>>>> different implementations: TCG injects #UD [1] while KVM sets x0 to -1 
> >>>>> [2].
> >>>> If the SMC or HVC insn isn't being used for PSCI then it should
> >>>> have its standard architectural behaviour.
> >>> Why?
> >> QEMU's assumption here is that there are basically two scenarios
> >> for these instructions:
> >>  (1) we're providing an emulation of firmware that uses this
> >>      instruction (and only this insn, not the other one) to
> >>      provide PSCI services
> >>  (2) we're not emulating any firmware at all, we're running it
> >>      in the guest, and that guest firmware is providing PSCI
> >>
> >> In case (1) we provide a PSCI ABI on the end of the insn.
> >> In case (2) we provide the architectural behaviour for the insn
> >> so that the guest firmware can use it.
> >>
> >> We don't currently have
> >>  (3) we're providing an emulation of firmware that does something
> >>      other than providing PSCI services on this instruction
> >>
> >> which is what I think you're asking for. (Alternatively, you might
> >> be after "provide PSCI via SMC, not HVC", ie use a different conduit.
> >> If hvf documents that SMC is guaranteed to trap that would be
> >> possible, I guess.)
> >>
> >>> Also, why does KVM behave differently?
> >> Looks like Marc made KVM set x0 to -1 for SMC calls in kernel commit
> >> c0938c72f8070aa; conveniently he's on the cc list here so we can
> >> ask him :-)
> > If we got a SMC trap into KVM, that's because the HW knows about it,
> > so injecting an UNDEF is rather counter productive (we don't hide the
> > fact that EL3 actually exists).
> 
> 
> This is the part where you and Peter disagree :). What would you suggest
> to do to create consistency between KVM and TCG based EL0/1 only VMs?

I don't think we disagree. We simply have different implementation
choices. The KVM "firmware" can only be used with HVC, and not
SMC. SMC is reserved for cases where the guest talks to the actual
EL3, or an emulation of it in the case of NV.

As for consistency between TGC and KVM, I have no plan for that
whatsoever. Both implementations are valid, and they don't have to be
identical. Even more, diversity is important, as it weeds out silly
assumptions that are baked in non-portable SW.

Windows doesn't boot? I won't loose any sleep over it.

> 
> > However, we don't implement anything on the back of this instruction,
> > so we just return NOT_IMPLEMENTED (-1). With NV, we actually use it as
> > a guest hypervisor can use it for PSCI and SMC is guaranteed to trap
> > even if EL3 doesn't exist in the HW.
> >
> > For the brain-damaged case where there is no EL3, SMC traps and the
> > hypervisor doesn't actually advertises EL3, that's likely a guest
> > bug. Tough luck.
> >
> > Side note: Not sure where HVF does, but on the M1 running Linux, SMC
> > appears to trap to EL2 with EC=0x3f, which is a reserved exception
> > class. This of course results in an UNDEF being injected because as
> > far as KVM is concerned, this should never happen.
>
> Could that be yet another magical implementation specific MSR bit that
> needs to be set? Hvf returns 0x17 (EC_AA64_SMC) for SMC calls.

That's possible, but that's not something KVM will do. Also, from what
I understand of HVF, this value is what you get in userspace, and it
says nothing of what the kernel side does. It could well be
translating the invalid EC into something else, after having read the
instruction from the guest for all I know.

It is pretty obvious that this HW is not a valid implementation of the
architecture and if it decides to screw itself up, I'm happy to
oblige.

        M.

-- 
Without deviation from the norm, progress is not possible.