linux-kernel - Re: [PATCH 2/3] firmware: arm_ffa: Setup of

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250121100946.ouzeuh5fopkgmf55@vireshk-i7>
Date: Tue, 21 Jan 2025 15:39:46 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Vincent Guittot <vincent.guittot@...aro.org>,
	Alex Bennée <alex.bennee@...aro.org>,
	Bill Mills <bill.mills@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] firmware: arm_ffa: Setup of_node for ffa devices

On 21-01-25, 09:59, Sudeep Holla wrote:
> On Tue, Jan 21, 2025 at 12:26:39PM +0530, Viresh Kumar wrote:
> > Match and bind the of_node for the FFA device.
> 
> I am bit confused and need more details than the above line 😄, because
> 
> 1. We don't have any binding for FF-A and compatible "arm,ffa" is not yet
>    defined

Realized now that you weren't cc'd on 1/3. Bounced it to your email id
now.

> 2. Even if we have binding, we will not have vm_id and UUID which are
>    discoverable from the firmware

Hmm..

> 3. DT maintainers rejected the bindings when it was initially proposed
>    as it is discoverable. If we need it for a valid reason, we need more
>    info, this patch doesn't provide full picture to change their stance.

We are working on FFA based Virtio bus/devices. The
dma_alloc_coherent() helpers for the virtqueue (and other DMA-ble
memory helpers) end up calling the dma-core for the parent device,
which is FFA device in our case.

We want to avoid separate mapping for each buffer sent by the guest
and keep a reserved mem (via DT) for the specific FFA device. With
that, the memory can be mapped at once at the host (shared over FFA)
and all the following DMA allocations can happen from that
memory-region.

This needs to come via DT and this was my first attempt to get the
discussion going.

> I would like to add minimal binding not for vmid or UUID but for interrupts
> only. It is still WIP but I haven't made up my mind on how that should look.

These were required to identify the exact FFA device from DT, what
else can we do ?

-- 
viresh