Subject: RE: [PATCH 00/26] KVM: vfio: Hide KVM internals from others

From: Shameerali Kolothum Thodi <[email-masked]>
Date: Thu, 20 Jun 2024 10:10:59 +0000

> -----Original Message-----
> From: Sean Christopherson <[email-masked]>
> Sent: Saturday, September 16, 2023 1:31 AM
> To: Catalin Marinas <[email-masked]>; Will Deacon
> <[email-masked]>; Marc Zyngier <[email-masked]>; Oliver Upton
> <[email-masked]>; Huacai Chen <[email-masked]>; Michael
> Ellerman <[email-masked]>; Anup Patel <[email-masked]>; Paul
> Walmsley <[email-masked]>; Palmer Dabbelt
> <[email-masked]>; Albert Ou <[email-masked]>; Heiko
> Carstens <[email-masked]>; Vasily Gorbik <[email-masked]>;
> Alexander Gordeev <[email-masked]>; Christian Borntraeger
> <[email-masked]>; Janosch Frank <[email-masked]>;
> Claudio Imbrenda <[email-masked]>; Thomas Gleixner
> <[email-masked]>; Ingo Molnar <[email-masked]>; Borislav Petkov
> <[email-masked]>; Dave Hansen <[email-masked]>;
> [email-masked]; Peter Zijlstra <[email-masked]>; Arnaldo Carvalho de
> Melo <[email-masked]>; Sean Christopherson <[email-masked]>;
> Paolo Bonzini <[email-masked]>; Tony Krowiak
> <[email-masked]>; Halil Pasic <[email-masked]>; Jason Herne
> <[email-masked]>; Harald Freudenberger <[email-masked]>;
> Alex Williamson <[email-masked]>; Andy Lutomirski
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; linux-
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; linux-
> [email-masked]; [email-masked]; linux-perf-
> [email-masked]; Anish Ghulati <[email-masked]>; Venkatesh
> Srinivas <[email-masked]>; Andrew Thornton
> <[email-masked]>
> Subject: [PATCH 00/26] KVM: vfio: Hide KVM internals from others
> 
> This is a borderline RFC series to hide KVM's internals from the rest of
> the kernel, where "internals" means data structures, enums, #defines,
> APIs, etc. that are intended to be KVM-only, but are exposed everywhere
> due to kvm_host.h (and other headers) living in the global include paths.
> 
> The motiviation for hiding KVM's internals is to allow *safely* loading a
> "new" KVM module without having to reboot the host.  Where "new" doesn't
> have to be strictly newer, just a different incarnation of KVM.  Hiding
> KVM's internals means those assets can change across KVM instances
> without
> breaking things, e.g. would allow modifying the layout of struct kvm_vcpu
> to introduce new fields related to a new feature or mitigation for hardware
> bugs.
> 
> The end goal for all of this is to allow loading and running multiple
> instances of KVM (the module) simultaneously on a single host, e.g. to
> deploy fixes, mitigations, and/or new features without having to drain
> all VMs from the host.
> 
> For now, the immediate goal is to get KVM to a state where KVM x86 doesn't
> expose anything to the broader world that isn't intended for external
> consumption, e.g. the page write-tracking APIs used by KVM-GT.
> 
> I say this is borderline RFC because I don't think I've "formally" proposed
> the idea of hiding KVM internals before now.  I decided not to tag this RFC
> because the changes ended up being not _that_ invasive, and everything
> before the last six patches is worthwhile even if hiding internals is
> ultimately rejected (IMO).
> 
> This would ideally be ~5 separate series, and I certainly have no objection
> if that's how we want to get this stuff merged.  E.g. (1) VFIO cleanups,
> (2) drop HAVE_KVM, (3) clean up makefiles, (4) x86 perf cleanup, and
> (5) final push for hiding state.  The HAVE_KVM and virt/kvm include stuff
> isn't strictly necessary, but I included them here because they're
> relatively minor (in the grand scheme).

Hi Sean,

Just thought of checking with you on this series. Do you have plans to revive this
series? The reason I am asking is, on ARM64/KVM side we do have a requirement
to share the KVM VMID with SMMUV3. Please see the RFC I sent out earlier this
year[1]. The series basically provides a way for KVM to pin a VMID and also
associates an iommufd ctx with a struct kvm * to retrieve that VMID. 

As mentioned above, some of the patches in this series(especially 1-4 & 6) that
does the VFIO cleanups and dropping CONFIG_KVM_VFIO looks very straightforward
and useful. I am thinking of including those when I re-spin my RFC series, if that’s ok.

Please let me know your thoughts.

Thanks,
Shameer

[1]. https://lore.kernel.org/linux-iommu/20240209115824.GA2922446@myrica/