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 6885FC001DE for ; Mon, 31 Jul 2023 09:38:26 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7218F86A5F; Mon, 31 Jul 2023 11:38:24 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="yZFsCxHF"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 43C1B8699C; Mon, 31 Jul 2023 11:38:23 +0200 (CEST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 1DF0486A55 for ; Mon, 31 Jul 2023 11:38:20 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-51cff235226so9009356a12.0 for ; Mon, 31 Jul 2023 02:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1690796299; x=1691401099; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=A3kxvjE958iWGqIYFDctXqGej/jNQ/TItGs9uqdr51c=; b=yZFsCxHFptbDHBKjIMqAQUFC4NfGIMDPs8WsSsW1Yu8PTe5DHZ4Y3fGxrqpTXCaWkP 7u+O7N3XCj/8Uvt0ymutruvkwjS/k/g4h8Aprt++mK5PmRN/SV9WJiA5mRXAnuOs03jM 6h8ILbSc7Y8qxr5PwBG9/VigDAzdgU6XDDUFcXuSiV/OvFeSae6i+xh3ftGi3aPQNRcX AGx2JDojlKrMEUiTQlvymvv7vcp3CzDnuC1rLq7GMaEmzA2aNnlB7mNiMzY+adpJbtGS CmzDYNCAtdzRZQGsMK1Pf5FXlSBTYFN5rYCQ2D339inBCHLumTSZAI4LB0COBUCQ0KT8 AboQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690796299; x=1691401099; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=A3kxvjE958iWGqIYFDctXqGej/jNQ/TItGs9uqdr51c=; b=BTz1qcewWU6x1+GFZxKbezbVjHGbqCrqyrFLMZb867u6qYF66q1g/ZE/MpCgVFkOz+ srUuF7ib2mlLJ/9Sw2iYLYn3HWnmDWqy5pExUjHOvqXbzolnmETApWDYQkv13j1pu585 h6tDacuXPvPTOCrivjJfAaOkDCTtI1rqoaHbJ8xdyLcfVHwSxSJFD5vs4c4vCzyHs4Yt GaxEJcAfdlGalVtNlTFQVP1L4TWa7iNuLe5auTDDfVibpk4/Tpf6sxZmYCytnhXrGHV2 R2BvLI0h7Zk17kYlgjGuEJXAnToFRyasGte/em2RVASkVQpzKwFkssZoJAN0kaMSrBnw 6Seg== X-Gm-Message-State: ABy/qLbnflGDT7S8Lxo7/MWRh0yWKMRaqh3NQ15aKrfH+vBnGgdCybVC 25SWjiSWMD58O3vcB1IJJWzXcQLnKDibJyKSvVU= X-Google-Smtp-Source: APBJJlHDblp0sspgNeHQCjTPpMHPt13GmbeG7xka5k2U+Eo7JabJ9JjRtKvWJwDVeoMt/ERBqIYPRQ== X-Received: by 2002:a05:6402:1e94:b0:51d:b184:efd with SMTP id f20-20020a0564021e9400b0051db1840efdmr14401029edf.20.1690796299522; Mon, 31 Jul 2023 02:38:19 -0700 (PDT) Received: from hades (ppp089210246083.access.hol.gr. [89.210.246.83]) by smtp.gmail.com with ESMTPSA id q26-20020aa7d45a000000b0051d9de03516sm5233777edr.52.2023.07.31.02.38.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jul 2023 02:38:19 -0700 (PDT) Date: Mon, 31 Jul 2023 12:38:16 +0300 From: Ilias Apalodimas To: Tom Rini Cc: Abdellatif El Khlifi , jens.wiklander@linaro.org, nd@arm.com, sjg@chromium.org, u-boot@lists.denx.de, Gowtham Suresh Kumar Subject: Re: [PATCH v17 09/10] arm_ffa: efi: introduce FF-A MM communication Message-ID: References: <20230726160635.GS3630934@bill-the-cat> <20230727160712.81477-1-abdellatif.elkhlifi@arm.com> <20230727160712.81477-10-abdellatif.elkhlifi@arm.com> <20230727164345.GH3630934@bill-the-cat> <20230728135415.GU3630934@bill-the-cat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230728135415.GU3630934@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 Fri, Jul 28, 2023 at 09:54:15AM -0400, Tom Rini wrote: > On Fri, Jul 28, 2023 at 02:00:25PM +0300, Ilias Apalodimas wrote: > > Hi Tom > > > > On Thu, 27 Jul 2023 at 19:43, Tom Rini wrote: > > > > > > On Thu, Jul 27, 2023 at 05:07:11PM +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 > > > > > > > > --- > > > > > > > > Changelog: > > > > =============== > > > > > > > > v17: > > > > > > > > * show a debug message rather than an error when FF-A is not detected > > > [snip] > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > index c5835e6ef6..8fbadb9201 100644 > > > > --- a/lib/efi_loader/Kconfig > > > > +++ b/lib/efi_loader/Kconfig > > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE > > > > stored as file /ubootefi.var on the EFI system partition. > > > > > > > > config EFI_MM_COMM_TEE > > > > - bool "UEFI variables storage service via OP-TEE" > > > > - depends on OPTEE > > > > + bool "UEFI variables storage service via the trusted world" > > > > + depends on OPTEE && ARM_FFA_TRANSPORT > > > > > > You didn't get my changes in here however. If you can do EFI_MM_COMM_TEE > > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig does) then > > > you don't make this option depend on . If FF-A is only > > > for use here, you make FF-A depend on this, and the FF-A specific > > > variable depend on ARM_FFA_TRANSPORT. > > > > Abdellatif hinted at what's going on here. When I added this Kconfig > > option to lx2160 FF-A wasn't implemented yet. > > The defconfig has existed since May 2020, which is when you added > EFI_MM_COMM_TEE itself too. So I think it's that no one did the check I > did until now and saw this series was disabling what was on the other > platform. > > > Since FF-A isn't a new > > communication mechanism but builds upon the existing SMCs to build an > > easier API, I asked Abdellatif to hide this complexity. > > We had two options, either make Kconfig options for either FF-A or the > > traditional SMCs and remove the dependencies, or piggyback on FF-As > > discovery mechanism and make the choice at runtime. The latter has a > > small impact on code size, but imho makes developers' life a lot > > easier. > > I'm not sure how much you can do a run-time option here since you're > setting a bunch of default values for FF-A to 0 in Kconfig. If we're > supposed to be able to get them at run time, we shouldn't need a Kconfig > option at all. I'm also not sure how valid a use case it is where we > won't know at build time what the rest of the firmware stack supports > here. > That's a fair point. FF-A in theory has APIs to discover memory. Abdellatif, why do we need the Kconfigs for shared memory on FF-A? Regards /Ilias > -- > Tom