One small question/remark: According to the the "Arm Power State Coordinate Interface" (DEN0022D.b) document (chapter 5) PSCI calls can only be issued by "normal world" (EL1 or EL2). Therefore, should we be adding a test for the current secure state in the arm_is_psci_call() function? This would prevent calling the built-in Qemu PSCI function if SMC is issued  from secure state. Regards. JC Le 06/11/2021 à 14:04, Jean-Christophe DUBOIS a écrit : > 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 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 >>>> >>> >> >