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

[Alexander Graf <agraf@csgraf.de>]

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?


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


Alex