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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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/





[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux