> -----Original Message----- > From: Sean Christopherson <sea...@google.com> > Sent: Monday, June 24, 2024 4:32 PM > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > Cc: 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>; 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>; 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: Re: [PATCH 00/26] KVM: vfio: Hide KVM internals from others > > On Thu, Jun 20, 2024, Shameerali Kolothum Thodi wrote: > > > 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. > > > > Hi Sean, > > > > Just thought of checking with you on this series. Do you have plans to > revive this > > series? > > Yep! > > > 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 don't include them, as the patch they build towards (patch 5) is > buggy[*], > and I am fairly certain that at least some of the patches will change > significantly.
Ok. Got it. Thanks for taking a look at the KVM pinned VMID series and comments there. Shameer
