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
