On 15.09.21 11:46, Marc Zyngier wrote: > On Mon, 13 Sep 2021 13:30:57 +0100, > Peter Maydell <peter.mayd...@linaro.org> wrote: >> On Mon, 13 Sept 2021 at 13:02, Alexander Graf <ag...@csgraf.de> wrote: >>> >>> On 13.09.21 13:44, Peter Maydell wrote: >>>> On Mon, 13 Sept 2021 at 12:07, Alexander Graf <ag...@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
