Re: Qemu and ARM secure state.

[Jean-Christophe DUBOIS]

So it seems that what is needed is a way to choose on the command line if we want to enable the Qemu built-in PSCI implementation (because we are booting linux for example) or if we really want a bare metal processor (because we are booting a trustedOS like optee).

The "virt" platform allows to dynamically choose one or the other. Other platforms seems to need the same feature.

JC

Le 06/11/2021 à 11:04, Jean-Christophe DUBOIS a écrit :

So, I am trying to understand:

Contrary to what I said, In my case the SMC instruction is not really a "no-op" as it sets R0 to -1 (0xffffffff) to indicate an unknown PSCI service (by the Qemu internal PSCI handler).

With the new code introduced by the "arm: tcg: Adhere to SMCCC 1.3 section 5.2" commit, once a processor/platform configure things to have PSCI requests handled by Qemu code (with "psci-conduit" attribute set to QEMU_PSCI_CONDUIT_SMC for example), then any exception raised by an "SMC" instruction will be only handled by the Qemu internal code and will no call the monitor related code in the guest/OS application. This seems to be why my SMC monitor handler is not called anymore in my case.

As my i.MX6UL is a mono-processor platform I don't really need to set the "psci-conduit" attribute (which really makes sense when you have a cluster of 2 or more cores I guess). As a matter of fact if I remove the "psci-conduit" attribute setting from the i.MX6UL processor file, my application is working again on main/latest.

But this still raises the question to know if the current behavior for processors with "psci-conduit" set to SMC or HVC is correct. For example an i.MX7 based platform (with up to 4 cortex A7 cores) would not be able to trigger OS SMC handler as the exception would be entirely processed by the Qemu internal code (with CR generally set to -1 in R0 to indicate unknown PSCI request).

Is there something I am missing?

Regards

JC

Le 04/11/2021 à 22:11, Jean-Christophe DUBOIS a écrit :

Le 04/11/2021 à 12:11, Peter Maydell a écrit :

On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS <jcd@tribudubois.net> wrote:

I have a little application that is designed to work on the i.MX6UL processor.

I developed it and tested it on the mcimx6ul-evk platform emulated by Qemu.

This application used to work "flawlessly" on Qemu 5.0.50 and is working on Qemu 6.0.0 (available as a pre-built package on the latest Ubuntu).

But when I try to run the exact same command line on a Qemu version I compile myself from main/latest of github (Qemu 6.1.50), my application fails to start.

So a little background:

My application expects to start in "secure" state and supervisor mode (which is the default state of i.MX6UL when booting barebone [without u-boot]).

>From this state the application tries to get to "non secure" / hypervisor mode which imply going to the "secure" / monitor state before being able to drop to "non secure" / hypervisor. To do so is runs a "smc 0" operand (from "secure" / supervisor).

This "smc" instruction is processed "as expected" by Qemu 5.0.50 and Qemu 6.0.0 (getting to "secure" / monitor mode) but on Qemu 6.1.50 (latest from github) it is as if the smc operand was a no-op. It doesn't trigger any exception and the processor just get to the next instruction after the "smc" instruction. So I am a bit puzzled.

Is there something that changed in Qemu (since Qemu 6.0.0) when it comes to the "secure" world/state?
Is there some additional command line parameters to use (I search in the documentation but without luck) to get secure world behavior ?
Is it necessary to "adapt" the emulated platform (i.MX6UL/mcimx6ul-evk) in some way (it looks like the "virt" machine with "secure=on" does work for arm platform)?

Could you try doing a bisect to find the QEMU commit that caused
your guest to stop working ?

OK, I did the bisect and the commit that break the i.MX6UL behavior for my program is commit 9fcd15b9193e819b6cc2fd0a45e3506148812bb4 (arm: tcg: Adhere to SMCCC 1.3 section 5.2).

Before it the SMC instruction would trigger a monitor exception.

After it the SMC instruction is acting like a no-op.

Thanks

JC

thanks
-- PMM