Re: [PATCH] target/arm: Treat unknown SMC calls as NOP

[Peter Maydell]

On Wed, 1 Jul 2020 at 21:08, Alexander Graf <agraf@csgraf.de> wrote:
>
> We currently treat unknown SMC calls as UNDEF. This behavior is different
> from KVM, which treats them as NOP.
>
> Unfortunately, the UNDEF exception breaks running Windows for ARM in QEMU,
> as that probes an OEM SMCCC call on boot, but does not expect to receive
> an UNDEF exception as response.
>
> So instead, let's follow the KVM path and ignore SMC calls that we don't
> handle. This fixes booting the Windows 10 for ARM preview in TCG for me.
>
> Signed-off-by: Alexander Graf <agraf@csgraf.de>

> +    if (cs->exception_index == EXCP_SMC &&
> +        !arm_feature(env, ARM_FEATURE_EL3) &&
> +        cpu->psci_conduit != QEMU_PSCI_CONDUIT_SMC) {

This condition says: "we got an SMC, and this CPU doesn't
have EL3, and we're not imitating real EL3 firmware".
The architecturally correct behaviour here (since we don't
implement nested-virt yet, which might allow it to trap
to guest EL2) is to UNDEF, as far as I can see from a quick
look at the AArch64.CheckForSMCUndefOrTrap().

I'm not sure why KVM makes these NOP; if I'm right about the
architectural behaviour then making them NOP would be a KVM bug.

If Windows makes an SMC call on boot that seems like a guest
bug: it would crash on a real CPU without EL2/EL3 as well.

      *  Conduit SMC, valid call  Trap to EL2         PSCI Call
      *  Conduit SMC, inval call  Trap to EL2         Undef insn
-     *  Conduit not SMC          Undef insn          Undef insn
+     *  Conduit not SMC          nop                 nop

The line in this table that your commit message says you're
fixing is "Conduit SMC, inval call"; the line your code
change affects is "Conduit not SMC", which is not the same
thing. (I'd have to look at the PSCI spec to see what it
requires for SMCs that aren't valid PSCI calls.)

thanks
-- PMM