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 3F203C433F5 for ; Thu, 4 Nov 2021 21:13:00 +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 981E36124F for ; Thu, 4 Nov 2021 21:12:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 981E36124F 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]:33706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mik2c-0000XX-JH for qemu-devel@archiver.kernel.org; Thu, 04 Nov 2021 17:12:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50588) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mik1E-000807-Ec; Thu, 04 Nov 2021 17:11:32 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:50079) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mik1B-00074j-Md; Thu, 04 Nov 2021 17:11:31 -0400 Received: (Authenticated sender: jcd@tribudubois.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 7EEEBFF805; Thu, 4 Nov 2021 21:11:23 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------jC5hRl0UNJFFVHOI7HwStT30" Message-ID: Date: Thu, 4 Nov 2021 22:11:22 +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 To: Peter Maydell References: <07e63acb-b756-2586-2ba2-b54b837f7fc8@tribudubois.net> From: Jean-Christophe DUBOIS In-Reply-To: Received-SPF: pass client-ip=217.70.183.199; envelope-from=jcd@tribudubois.net; helo=relay9-d.mail.gandi.net X-Spam_score_int: -46 X-Spam_score: -4.7 X-Spam_bar: ---- X-Spam_report: (-4.7 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-2.093, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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. --------------jC5hRl0UNJFFVHOI7HwStT30 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > --------------jC5hRl0UNJFFVHOI7HwStT30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
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


--------------jC5hRl0UNJFFVHOI7HwStT30--