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

[Alexander Graf <agraf@csgraf.de>]

On 13.09.21 14:30, Peter Maydell 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.)


Hvf doesn't document anything. The only documentation it has are its C
headers.

However, M1 does not implement EL3, but traps SMC calls. It's the only
chip Apple has out for hvf on ARM today. I would be very surprised if
they started to regress on that functionality.

So, would you be open to changing the default conduit to SMC for
hvf_enabled()? Is that really a better experience than just modeling
behavior after KVM?


>
>> 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 :-)
>
>> And why does Windows rely on
>> SMC availability on boot?
> Ask Microsoft, but probably either they don't realize that
> SMC might not exist and be trappable, or they only have a limited
> set of hosts they care about. CPUs with no EL3 are not that common.


I'm pretty sure it's the latter :).


>
>> If you really insist that you don't care about users running Windows
>> with TCG and EL2=0, so be it. At least you can enable EL2 and it works
>> then. But I can't on hvf. It's one of the most useful use cases for hvf
>> on QEMU and I won't break it just because you insist that "SMC behavior
>> is IMPDEF, so it must be UNDEF". If it's IMPDEF, it may as well be "set
>> x0 to -1 and add 4 to pc".
> I am not putting in random hacks for the benefit of specific guest OSes.
> If there's a good reason why QEMU's behaviour is wrong then we can change
> it, but "I want Windows to boot" doesn't count.


Ok, so today we have 2 implementations for SMC traps in an EL0/1 only VM:

  * TCG injects #UD
  * KVM sets x0 = -1 and pc += 4.

With v10 of the HVF patch set, I'm following what KVM is doing. Can we
leave it at that for now and sort out with Marc (and maybe ARM spec
writers) what we want to do consistently across all implementations as a
follow-up?


Thanks,

Alex