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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D14C0C001DC for ; Thu, 27 Jul 2023 09:35:19 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C2C29867D9; Thu, 27 Jul 2023 11:35:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 2524E86768; Thu, 27 Jul 2023 11:35:11 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id CB1B286768 for ; Thu, 27 Jul 2023 11:35:02 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=abdellatif.elkhlifi@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 87BCED75; Thu, 27 Jul 2023 02:35:44 -0700 (PDT) Received: from e130802.arm.com (unknown [10.57.1.239]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A34EF3F5A1; Thu, 27 Jul 2023 02:34:59 -0700 (PDT) Date: Thu, 27 Jul 2023 10:34:50 +0100 From: Abdellatif El Khlifi To: Tom Rini Cc: gowtham.sureshkumar@arm.com, ilias.apalodimas@linaro.org, jens.wiklander@linaro.org, meenakshi.aggarwal@nxp.com, nd@arm.com, priyanka.jain@nxp.com, sjg@chromium.org, u-boot@lists.denx.de, wasim.khan@nxp.com Subject: Re: [PATCH v16 09/10] arm_ffa: efi: introduce FF-A MM communication Message-ID: <20230727093450.GA56607@e130802.arm.com> References: <20230725185246.GE3630934@bill-the-cat> <20230726094503.100497-1-abdellatif.elkhlifi@arm.com> <20230726094503.100497-10-abdellatif.elkhlifi@arm.com> <20230726193912.GX3630934@bill-the-cat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230726193912.GX3630934@bill-the-cat> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean Hi Tom, On Wed, Jul 26, 2023 at 03:39:12PM -0400, Tom Rini wrote: > On Wed, Jul 26, 2023 at 10:45:02AM +0100, Abdellatif El Khlifi wrote: > > > Add MM communication support using FF-A transport > > > > This feature allows accessing MM partitions services through > > EFI MM communication protocol. MM partitions such as StandAlonneMM > > or smm-gateway secure partitions which reside in secure world. > > > > An MM shared buffer and a door bell event are used to exchange > > the data. > > > > The data is used by EFI services such as GetVariable()/SetVariable() > > and copied from the communication buffer to the MM shared buffer. > > > > The secure partition is notified about availability of data in the > > MM shared buffer by an FF-A message (door bell). > > > > On such event, MM SP can read the data and updates the MM shared > > buffer with the response data. > > > > The response data is copied back to the communication buffer and > > consumed by the EFI subsystem. > > > > MM communication protocol supports FF-A 64-bit direct messaging. > > > > Signed-off-by: Abdellatif El Khlifi > > Tested-by: Gowtham Suresh Kumar > > Reviewed-by: Simon Glass > > Cc: Tom Rini > > Cc: Ilias Apalodimas > > Cc: Jens Wiklander > > So, at this point in the series we impact lx2160ardb_tfa_stmm which is > the only config in the tree prior to this series that sets > CONFIG_EFI_MM_COMM_TEE. I'm not going to block this series[1] on > updating lx2160ardb_tfa_stmm as well, but I do want to make sure the > maintainers there are aware and can update the config to support the > current state of this technology. > > [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=365876&state=* > -- Following a decision made with Ilias, the new MM comms design works as follows: - Try to communicate using FF-A bus first - If that fails, try to communicate using Optee. So, platforms that don't support FF-A in the Secure side can still use Optee communication This is done through the code below [1]. This logic needs CONFIG_ARM_FFA_TRANSPORT=y in the defconfig. I added CONFIG_ARM_FFA_TRANSPORT=y to lx2160ardb_tfa_stmm_defconfig, CONFIG_EFI_MM_COMM_TEE is enabled and it builds fine. Is it expected that lx2160ardb_tfa_stmm maintainers add CONFIG_ARM_FFA_TRANSPORT=y to lx2160ardb_tfa_stmm_defconfig ? Cheers Abdellatif [1]: Selecting the MM comms method: static efi_status_t mm_communicate(u8 *comm_buf, efi_uintn_t dsize) ... mm_comms = get_mm_comms(); if (mm_comms == MM_COMMS_FFA) ret = ffa_mm_communicate(comm_buf, dsize); else ret = optee_mm_communicate(comm_buf, dsize);