From: Sudeep Holla <sudeep.holla@arm.com>
To: Sebastian Ene <sebastianene@google.com>
Cc: linux-arm-kernel@lists.infradead.org,
Marc Bonnici <marc.bonnici@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Olivier Deprez <Olivier.Deprez@arm.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Bertrand Marquis <Bertrand.Marquis@arm.com>,
Jens Wiklander <jens.wiklander@linaro.org>
Subject: Re: [PATCH v2 1/3] firmware: arm_ffa: Skip creation of the notification bitmaps
Date: Fri, 12 Apr 2024 12:31:37 +0100 [thread overview]
Message-ID: <ZhkbmX-khNSKqSY2@bogus> (raw)
In-Reply-To: <ZhkP__aSXl0wbazy@google.com>
On Fri, Apr 12, 2024 at 10:42:07AM +0000, Sebastian Ene wrote:
> On Thu, Apr 11, 2024 at 01:57:32PM +0100, Sudeep Holla wrote:
> > From: Jens Wiklander <jens.wiklander@linaro.org>
> >
> > When the FF-A driver is running inside a guest VM under an hypervisor,
> > the driver/guest VM doesn't have the permission/capability to request
> > the creation of notification bitmaps. For a VM, the hypervisor reserves
>
> Who restrains them from having this capability ? (to use the
> FFA_NOTIFICATION_BITMAP_CREATE API).
The hypervisor has to IIUC from the spec as it is responsible for creating
the bitmaps on its behalf. It can trap and handle those calls if it prefers
to fail for FFA_FEATURES(FFA_NOTIFICATION_BITMAP_CREATE).
> > memory for its VM and hypervisor framework notification bitmaps and the
> > SPMC reserves memory for its SP and SPMC framework notification bitmaps
> > before the hypervisor initializes it.
> >
> > The hypervisor does not initialize a VM if memory cannot be reserved
> > for all its notification bitmaps. So the creation of all the necessary
> > bitmaps are already done when the driver initialises and hence it can be
> > skipped. We rely on FFA_FEATURES(FFA_NOTIFICATION_BITMAP_CREATE) to fail
> > when running in the guest to handle this in the driver.
> >
>
> This implies that the hypervisor reserves memory in advance to keep the
> notification bitmaps even though the guest might decide not to use them.
> For pKVM this assumption does not work because we might have guests that will not be
> allowed to talk to TZ.
>
Sure, in such case pKVM can always trap and fail for FFA_VERSION call so
that no further FFA transactions happen from that guest or just fail for
notification APIs if the notifications alone are not needed.
Hope that clarifies.
> > Signed-off-by:Jens Wiklander <jens.wiklander@linaro.org>
> > [sudeep.holla: Updated the commit message]
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> > drivers/firmware/arm_ffa/driver.c | 16 +++++++---------
> > 1 file changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> > index f2556a8e9401..4a576af7b8fd 100644
> > --- a/drivers/firmware/arm_ffa/driver.c
> > +++ b/drivers/firmware/arm_ffa/driver.c
> > @@ -1442,17 +1442,15 @@ static void ffa_notifications_setup(void)
> > int ret, irq;
> >
> > ret = ffa_features(FFA_NOTIFICATION_BITMAP_CREATE, 0, NULL, NULL);
> > - if (ret) {
> > - pr_info("Notifications not supported, continuing with it ..\n");
> > - return;
> > - }
> > + if (!ret) {
> > + ret = ffa_notification_bitmap_create();
> > + if (ret) {
> > + pr_info("Notification bitmap create error %d\n", ret);
>
> Not a big deal but shouldn't this be a pr_err(..)
>
Sure I can fixup when I apply.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-12 11:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 12:57 [PATCH v2 0/3] firmware: arm_ffa: Add support to run inside a guest/VM under a hypervisor Sudeep Holla
2024-04-11 12:57 ` [PATCH v2 1/3] firmware: arm_ffa: Skip creation of the notification bitmaps Sudeep Holla
2024-04-12 10:42 ` Sebastian Ene
2024-04-12 11:31 ` Sudeep Holla [this message]
2024-04-11 12:57 ` [PATCH v2 2/3] firmware: arm_ffa: Refactor SRI handling in prepartion to add NPI support Sudeep Holla
2024-04-11 12:57 ` [PATCH v2 3/3] firmware: arm_ffa: Add support for handling notification pending interrupt(NPI) Sudeep Holla
2024-04-11 13:30 ` [PATCH v2 0/3] firmware: arm_ffa: Add support to run inside a guest/VM under a hypervisor Jens Wiklander
2024-04-11 14:30 ` Sudeep Holla
2024-04-18 10:01 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZhkbmX-khNSKqSY2@bogus \
--to=sudeep.holla@arm.com \
--cc=Bertrand.Marquis@arm.com \
--cc=Olivier.Deprez@arm.com \
--cc=jens.wiklander@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=marc.bonnici@arm.com \
--cc=sebastianene@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).