From: Sudeep Holla <sudeep.holla@arm.com>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: linux-kernel@vger.kernel.org,
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>
Subject: Re: [PATCH v2] firmware: arm_ffa: support running as a guest in a vm
Date: Tue, 26 Mar 2024 15:35:31 +0000 [thread overview]
Message-ID: <ZgLrQ7FtDy3INX8F@bogus> (raw)
In-Reply-To: <20240325081335.2326979-1-jens.wiklander@linaro.org>
On Mon, Mar 25, 2024 at 09:13:35AM +0100, Jens Wiklander wrote:
> Add support for running the driver in a guest to a hypervisor. The main
> difference is introducing notification pending interrupt and that
> FFA_NOTIFICATION_BITMAP_CREATE doesn't need to be called.
>
> The guest may need to use a notification pending interrupt instead of or
> in addition to the schedule receiver interrupt.
The above statement makes me worry a bit that we are still not on the same
page about NPI vs SRI. NPI need not exist in addition to SRI. And in v1
you did mention you have SRI in the guest as well. Then why do we need
NPI in addition to that. As part of SRI, the callback ffa_self_notif_handle
gets registered and will be called as part of SRI handling. What you
do in notif_pend_irq_handler(), exactly what ffa_self_notif_handle()
already does.
I am still struggling to understand the usecase here. If you just have
NPI and no SRI when running the driver in the VM, then it aligns with
my understanding of possible use-case(not the one you mentioned in v1:
where FF-A driver in VM will have SRI as OPTEE is the secondary scheduler)
If we are supporting NPI or SRI, I think we can see if we can further
simplify this change, but I want to get to an agreement with usage model
before we dig into implementation details in this patch.
--
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-03-26 15:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 8:13 [PATCH v2] firmware: arm_ffa: support running as a guest in a vm Jens Wiklander
2024-03-26 15:35 ` Sudeep Holla [this message]
2024-03-27 9:23 ` Jens Wiklander
2024-04-03 13:03 ` Sudeep Holla
2024-04-03 14:27 ` Jens Wiklander
2024-04-10 11:45 ` 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=ZgLrQ7FtDy3INX8F@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=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=marc.bonnici@arm.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