> -----Original Message----- > From: Sean Christopherson <seanjc@xxxxxxxxxx> > Sent: Saturday, September 16, 2023 1:31 AM > To: Catalin Marinas <catalin.marinas@xxxxxxx>; Will Deacon > <will@xxxxxxxxxx>; Marc Zyngier <maz@xxxxxxxxxx>; Oliver Upton > <oliver.upton@xxxxxxxxx>; Huacai Chen <chenhuacai@xxxxxxxxxx>; Michael > Ellerman <mpe@xxxxxxxxxxxxxx>; Anup Patel <anup@xxxxxxxxxxxxxx>; Paul > Walmsley <paul.walmsley@xxxxxxxxxx>; Palmer Dabbelt > <palmer@xxxxxxxxxxx>; Albert Ou <aou@xxxxxxxxxxxxxxxxx>; Heiko > Carstens <hca@xxxxxxxxxxxxx>; Vasily Gorbik <gor@xxxxxxxxxxxxx>; > Alexander Gordeev <agordeev@xxxxxxxxxxxxx>; Christian Borntraeger > <borntraeger@xxxxxxxxxxxxx>; Janosch Frank <frankja@xxxxxxxxxxxxx>; > Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx>; Thomas Gleixner > <tglx@xxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; Borislav Petkov > <bp@xxxxxxxxx>; Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>; > x86@xxxxxxxxxx; Peter Zijlstra <peterz@xxxxxxxxxxxxx>; Arnaldo Carvalho de > Melo <acme@xxxxxxxxxx>; Sean Christopherson <seanjc@xxxxxxxxxx>; > Paolo Bonzini <pbonzini@xxxxxxxxxx>; Tony Krowiak > <akrowiak@xxxxxxxxxxxxx>; Halil Pasic <pasic@xxxxxxxxxxxxx>; Jason Herne > <jjherne@xxxxxxxxxxxxx>; Harald Freudenberger <freude@xxxxxxxxxxxxx>; > Alex Williamson <alex.williamson@xxxxxxxxxx>; Andy Lutomirski > <luto@xxxxxxxxxx> > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; kvmarm@xxxxxxxxxxxxxxx; linux- > mips@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx; > kvm-riscv@xxxxxxxxxxxxxxxxxxx; linux-riscv@xxxxxxxxxxxxxxxxxxx; linux- > s390@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-perf- > users@xxxxxxxxxxxxxxx; Anish Ghulati <aghulati@xxxxxxxxxx>; Venkatesh > Srinivas <venkateshs@xxxxxxxxxxxx>; Andrew Thornton > <andrewth@xxxxxxxxxx> > 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/
