Re: [RFC PATCH v1 0/8] Arm Core Local Accelerator Driver

[Will Deacon]

Hi Ryan,

I haven't bothered to look at the code (looks like Sashiko is having fun
with that), but I'm going to jump at this bit:

On Fri, Jul 17, 2026 at 11:47:44AM +0100, Ryan Roberts wrote:
> * User space availability: The kernel driver exposes the capabilities of the
>   hardware to user space. Arm plans to open source a user space driver, but does
>   not yet have any committed date. I'd like to understand if the availability of
>   this component will be a prerequisite for upstream acceptance of the kernel
>   driver; either way, I'm hoping we can at least progress with some discussion
>   in its absence.

>From my perspective, I'm not particularly interested in having code in
the upstream kernel tree that we can't meaningfully exercise or benefit
from. I also think that the incentive for Arm to open source the
user-space driver practically disappears if we merge the kernel part
first. So, at the moment, this just looks like a burden to me, especially
as it appears to create a brand new, device-specific UAPI for what is
ostensibly a form of SVA - something which the community is actively
working on already.

Relatedly, is there a spec and/or fastmodel/qemu (sorry...) support for
this?

> I'm deliberately constraining the scope to bare-metal support for now.
> Virtualization is something we are considering (and have prototyped), but plan
> to post a separate RFC for that as follow-up, once we have agreement on
> direction for the bare-metal driver.

I'd actually like to see what the virtualisation part looks like first
because doing it as a bolt-on later feels like the wrong approach. The
structure you have at the moment is remarkably clean, given the
architectural/CPU interactions (this thing even apparently builds as a
module, nice!), but I'm unsure how far you can push the separation once
you need to start hacking at KVM. Maybe the MMU notifiers are enough,
but I can't tell.

Will