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: <20250124223045.GA2512712-robh@kernel.org>
Date: Fri, 24 Jan 2025 16:30:45 -0600
From: Rob Herring <robh@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Sudeep Holla <sudeep.holla@....com>,
	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 Tue, Jan 21, 2025 at 03:39:46PM +0530, Viresh Kumar wrote:
> 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.

For background, go read this thread[1]. :)

> 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.

Well, that's a better explanation than the patches have as they just 
appear to ignore all the history here.

But I still don't really understand. I know next to 0 about FF-A. Sounds 
like OS specific problems to me though.

Rob

[1] https://lore.kernel.org/all/20220329151659.16894-1-abdellatif.elkhlifi@arm.com/#r