> -----Original Message----- > From: Sean Christopherson <sea...@google.com> > Sent: Saturday, September 16, 2023 1:31 AM > To: Catalin Marinas <catalin.mari...@arm.com>; Will Deacon > <w...@kernel.org>; Marc Zyngier <m...@kernel.org>; Oliver Upton > <oliver.up...@linux.dev>; Huacai Chen <chenhua...@kernel.org>; Michael > Ellerman <m...@ellerman.id.au>; Anup Patel <a...@brainfault.org>; Paul > Walmsley <paul.walms...@sifive.com>; Palmer Dabbelt > <pal...@dabbelt.com>; Albert Ou <a...@eecs.berkeley.edu>; Heiko > Carstens <h...@linux.ibm.com>; Vasily Gorbik <g...@linux.ibm.com>; > Alexander Gordeev <agord...@linux.ibm.com>; Christian Borntraeger > <borntrae...@linux.ibm.com>; Janosch Frank <fran...@linux.ibm.com>; > Claudio Imbrenda <imbre...@linux.ibm.com>; Thomas Gleixner > <t...@linutronix.de>; Ingo Molnar <mi...@redhat.com>; Borislav Petkov > <b...@alien8.de>; Dave Hansen <dave.han...@linux.intel.com>; > x...@kernel.org; Peter Zijlstra <pet...@infradead.org>; Arnaldo Carvalho de > Melo <a...@kernel.org>; Sean Christopherson <sea...@google.com>; > Paolo Bonzini <pbonz...@redhat.com>; Tony Krowiak > <akrow...@linux.ibm.com>; Halil Pasic <pa...@linux.ibm.com>; Jason Herne > <jjhe...@linux.ibm.com>; Harald Freudenberger <fre...@linux.ibm.com>; > Alex Williamson <alex.william...@redhat.com>; Andy Lutomirski > <l...@kernel.org> > Cc: linux-arm-ker...@lists.infradead.org; kvm...@lists.linux.dev; linux- > m...@vger.kernel.org; k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > kvm-ri...@lists.infradead.org; linux-ri...@lists.infradead.org; linux- > s...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-perf- > us...@vger.kernel.org; Anish Ghulati <aghul...@google.com>; Venkatesh > Srinivas <venkate...@chromium.org>; Andrew Thornton > <andre...@google.com> > 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/
