Re: Qemu and ARM secure state.

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

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

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<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: 8634 bytes --]