qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [PATCH] target/arm: Treat unknown SMC calls as NOP
Date: Thu, 2 Jul 2020 11:02:10 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0


On 02.07.20 09:54, Alex Bennée wrote:
Alexander Graf <agraf@csgraf.de> writes:

On 01.07.20 22:47, Peter Maydell wrote:
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".

I like to think of it as "This CPU exposes an environment that looks
like KVM, so it implements HVC calls (EL2) and is responsible for
handling SMC calls as well.
That is a very KVM centric view of the world ;-)

I thought the aim was always to behave as the real processor would.


If we aim to behave like a "real processor", then why do we implement PSCI using HVC? A much more likely "real processor" would implement EL3, but no EL2 and then have PSCI as SMC calls, no?

My understanding for the rationale on why we do PSCI over HVC by default was to make the VM as similar between KVM and TCG as possible.



The main difference between the two semantics is that in yours, you
don't have EL3. In mine, there is an EL3, but it's virtualized by the
same layer that implements EL2.
If you boot up with secure firmware + EL2 aware KVM kernel I assume
everything behaves as expected?


I would assume so as well, but I don't have a working ATF setup handy. I'm also not worried about making it work for me - I have my local debug setup now :). I'm worried about a good out of the box experience for users who want to run Windows on ARM in TCG.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]