On 17/07/2026 13:09, Marc Zyngier wrote: > Thanks Will for roping me in.
Sorry - I intentionally didn't include you because last time we spoke you said you were only really interested in discussions on the virt side of things and I didn't want to spam your inbox. Perhaps the wrong decision... > > On Fri, 17 Jul 2026 12:33:17 +0100, > Will Deacon <[email protected]> wrote: >> >>> 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. > > +1. > > Virtualisation cannot be a "bolt on the side" exercise. It is an > integral part of the arm64 tree, particularly for memory management > and scheduling, all of which have a direct impact on KVM. > > I don't think we can really evaluate anything here without looking at > the full picture. OK understood - as per reply to Will, we'll prioritise doing a version with virt support. Thanks, Ryan > > Thanks, > > M. >
