From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4043DC433F5 for ; Sat, 6 Nov 2021 10:06:18 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ACC20611C0 for ; Sat, 6 Nov 2021 10:06:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ACC20611C0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=tribudubois.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:39794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mjIaW-0007FK-QE for qemu-devel@archiver.kernel.org; Sat, 06 Nov 2021 06:06:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjIYc-0005t0-Ex; Sat, 06 Nov 2021 06:04:18 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:60793) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjIYZ-0004MJ-Ix; Sat, 06 Nov 2021 06:04:18 -0400 Received: (Authenticated sender: jcd@tribudubois.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 64187E0007; Sat, 6 Nov 2021 10:04:09 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------3ReN9D51jAnO062HfSsQ2RFW" Message-ID: Date: Sat, 6 Nov 2021 11:04:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: Qemu and ARM secure state. Content-Language: en-US From: Jean-Christophe DUBOIS To: Peter Maydell References: <07e63acb-b756-2586-2ba2-b54b837f7fc8@tribudubois.net> In-Reply-To: Received-SPF: pass client-ip=217.70.183.196; envelope-from=jcd@tribudubois.net; helo=relay4-d.mail.gandi.net X-Spam_score_int: -59 X-Spam_score: -6.0 X-Spam_bar: ------ X-Spam_report: (-6.0 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.407, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-arm , QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" This is a multi-part message in MIME format. --------------3ReN9D51jAnO062HfSsQ2RFW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 >> > --------------3ReN9D51jAnO062HfSsQ2RFW Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
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



--------------3ReN9D51jAnO062HfSsQ2RFW--