Re: Qemu and ARM secure state.

[Jean-Christophe DUBOIS <jcd@tribudubois.net>]

[-- Attachment #1: Type: text/plain, Size: 4399 bytes --]

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
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 7245 bytes --]