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

[Alexander Graf]

On 13.09.21 13:44, Peter Maydell wrote:
> On Mon, 13 Sept 2021 at 12:07, Alexander Graf <agraf@csgraf.de> wrote:
>>
>> On 13.09.21 10:54, Peter Maydell wrote:
>>> Something in here should be checking whether the insn the guest
>>> used matches the PSCI conduit configured for the VM, ie
>>> what arm_is_psci_call() does after your patch 10.
>>
>> It's yet another case where I believe we are both reading the spec
>> differently :)
>>
>>   https://documentation-service.arm.com/static/6013e5faeee5236980d08619
>>
>> Section 2.5.3 speaks about the conduits. It says
>>
>>     Service calls are expected to be invoked through SMC instructions,
>> except
>>     for Standard Hypervisor Calls and Vendor Specific Hypervisor Calls. On
>>     some platforms, however, SMC instructions are not available, and the
>>     services can be accessed through HVC instructions. The method that
>>     is used to invoke the service is referred to as the conduit.
>>
>> To me, that reads like "Use SMC whenever you can. If your hardware does
>> not give you a way to handle SMC calls, falling back to HVC is ok. In
>> that case, indicate that mandate to the OS".
> QEMU here is being the platform, so we define what the conduit is
> (or if one even exists). For the virt board this is "if the
> guest has EL3 firmware, then the guest firmware is providing PSCI,
> and QEMU should not; otherwise if the guest has EL2 then QEMU's
> emulated firmware should be at EL3 using SMC, otherwise use HVC".
>
> (So in practice for hvf at the moment this will mean the conduit
> is always HVC, since hvf doesn't allow EL3 or EL2 in the guest.)
>
>> In hvf, we can very easily trap for SMC calls and handle them. Why are
>> we making OSs implement HVC call paths when SMC would work just as well
>> for everyone?
> OSes have to handle both anyway, because on real hardware if
> there is no EL3 then it is IMPDEF whether SMC is trappable
> to the hypervisor or whether it just UNDEFs to EL1.
>
>> 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? Also, why does KVM behave differently? And why does Windows rely on
SMC availability on boot?

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

And yes, this is a hill I will die on :)


Alex