On Mon, 7 Sep 2020 at 12:32, Achin Gupta <Achin.Gupta@xxxxxxx> wrote:
>
> Hi Sudeep,
>
> CIL...
>
> > On 29 Aug 2020, at 18:09, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
> >
> > In order to also enable in-kernel users of FFA interface along with
> > the access to user-space applications, let us add simple set of operations
> > for such devices.
> >
> > The in-kernel users are registered without the character device interface.
> >
> > Signed-off-by: Sudeep Holla <sudeep.holla@xxxxxxx>
> > ---
> > drivers/firmware/arm_ffa/driver.c | 119 ++++++++++++++++++++++++++----
> > include/linux/arm_ffa.h | 12 +++
> > 2 files changed, 117 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> > index 96113e594db6..811558ef2a1d 100644
> > --- a/drivers/firmware/arm_ffa/driver.c
> > +++ b/drivers/firmware/arm_ffa/driver.c
> > @@ -372,6 +372,97 @@ static void ffa_device_put(struct ffa_device *ffa_dev)
> > mutex_unlock(&ffa_dev->mutex);
> > }
> >
> > +static int ffa_dev_open(struct ffa_device *ffa_dev)
> > +{
> > + ffa_device_get(ffa_dev);
> > +
> > + return 0;
> > +}
> > +
> > +static int ffa_dev_close(struct ffa_device *ffa_dev)
> > +{
> > + ffa_device_put(ffa_dev);
> > +
> > + return 0;
> > +}
> > +
> > +static long
> > +ffa_dev_ioctl(struct ffa_device *ffa_dev, unsigned int ioctl, void *arg)
> > +{
> > + long r = -EINVAL;
> > +
> > + switch (ioctl) {
> > + case FFA_GET_API_VERSION:
> > + r = drv_info->version;
> > + break;
> > + case FFA_GET_PARTITION_ID:
> > + r = ffa_dev->vm_id;
> > + break;
> > + case FFA_GET_PARTITION_INFO: {
> > + struct ffa_part_info *pinfo = arg;
> > +
> > + if (ffa_partition_probe(pinfo->uuid_str, &pinfo->info) != 1)
> > + r = -E2BIG;
> > + break;
> > + }
> > + case FFA_SEND_RECEIVE_SYNC: {
> > + struct ffa_send_recv_sync *kdata = arg;
> > +
> > + r = ffa_msg_send_direct_req(ffa_dev->vm_id, kdata->endpoint_id,
> > + &kdata->data);
> > + break;
> > + }
> > + case FFA_SEND_RECEIVE_ASYNC: {
>
> For indirect messaging, I am thinking who is responsible for creating and managing the “threads” for each vCPU of a FF-A VM that has an in-kernel user.
>
> An approach is the one taken by the Hafnium driver [1]. It creates and manages a kthread for each vCPU of each VM.
>
> A client of the Hafnium driver only needs to worry about message exchange with various VMs. Thread management is Hafnium specific and rightly stays in the Hafnium module instead of being replicated in each client.
>
> Is this the direct of travel for the FF-A driver as well?
I think what we want for the Android case at least is for these
threads to be managed in userspace by crosvm, following the
(Protected) KVM model.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
