Date: Thu, 20 Jun 2024 10:10:59 +0000
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
To: Sean Christopherson <seanjc@...gle.com>, Catalin Marinas
	<catalin.marinas@....com>, Will Deacon <will@...nel.org>, Marc Zyngier
	<maz@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>, Huacai Chen
	<chenhuacai@...nel.org>, Michael Ellerman <mpe@...erman.id.au>, Anup Patel
	<anup@...infault.org>, Paul Walmsley <paul.walmsley@...ive.com>, "Palmer
 Dabbelt" <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, "Heiko
 Carstens" <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, "Alexander
 Gordeev" <agordeev@...ux.ibm.com>, Christian Borntraeger
	<borntraeger@...ux.ibm.com>, Janosch Frank <frankja@...ux.ibm.com>, "Claudio
 Imbrenda" <imbrenda@...ux.ibm.com>, Thomas Gleixner <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
	<dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "Peter
 Zijlstra" <peterz@...radead.org>, Arnaldo Carvalho de Melo <acme@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>, Tony Krowiak <akrowiak@...ux.ibm.com>,
	Halil Pasic <pasic@...ux.ibm.com>, Jason Herne <jjherne@...ux.ibm.com>,
	Harald Freudenberger <freude@...ux.ibm.com>, Alex Williamson
	<alex.williamson@...hat.com>, Andy Lutomirski <luto@...nel.org>
CC: "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "kvmarm@...ts.linux.dev"
	<kvmarm@...ts.linux.dev>, "linux-mips@...r.kernel.org"
	<linux-mips@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"kvm-riscv@...ts.infradead.org" <kvm-riscv@...ts.infradead.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>, "Anish
 Ghulati" <aghulati@...gle.com>, Venkatesh Srinivas <venkateshs@...omium.org>,
	Andrew Thornton <andrewth@...gle.com>
Subject: RE: [PATCH 00/26] KVM: vfio: Hide KVM internals from others



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

Powered by blists - more mailing lists