linux-kernel - Re: [PATCH] KVM: s390: pci: Hook to access KVM lowlevel from VFIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 18 Aug 2022 17:22:40 +0200
From:   Niklas Schnelle <schnelle@...ux.ibm.com>
To:     Matthew Rosato <mjrosato@...ux.ibm.com>,
        Pierre Morel <pmorel@...ux.ibm.com>
Cc:     rdunlap@...radead.org, linux-kernel@...r.kernel.org, lkp@...el.com,
        farman@...ux.ibm.com, linux-s390@...r.kernel.org,
        kvm@...r.kernel.org, gor@...ux.ibm.com, hca@...ux.ibm.com,
        Janosch Frank <frankja@...ux.ibm.com>
Subject: Re: [PATCH] KVM: s390: pci: Hook to access KVM lowlevel from VFIO

On Thu, 2022-08-18 at 11:13 -0400, Matthew Rosato wrote:
> On 8/18/22 10:20 AM, Niklas Schnelle wrote:
> > On Thu, 2022-08-18 at 09:33 -0400, Matthew Rosato wrote:
> > > On 8/18/22 6:23 AM, Pierre Morel wrote:
> > > > We have a cross dependency between KVM and VFIO.
> > > 
> > > maybe add something like 'when using s390 vfio_pci_zdev extensions for PCI passthrough'
> > > 
> > > > To be able to keep both subsystem modular we add a registering
> > > > hook inside the S390 core code.
> > > > 
> > > > This fixes a build problem when VFIO is built-in and KVM is built
> > > > as a module or excluded.
> > > 
> > > s/or excluded//
> > > 
> > > There's no problem when KVM is excluded, that forces CONFIG_VFIO_PCI_ZDEV_KVM=n because of the 'depends on S390 && KVM'.
> > > 
> > > > Reported-by: Randy Dunlap <rdunlap@...radead.org>
> > > > Reported-by: kernel test robot <lkp@...el.com>
> > > > Signed-off-by: Pierre Morel <pmorel@...ux.ibm.com>
> > > > Fixes: 09340b2fca007 ("KVM: s390: pci: add routines to start/stop inter..")
> > > > Cc: <stable@...r.kernel.org>
> > > > ---
> > > >  arch/s390/include/asm/kvm_host.h | 17 ++++++-----------
> > > >  arch/s390/kvm/pci.c              | 10 ++++++----
> > > >  arch/s390/pci/Makefile           |  2 ++
> > > >  arch/s390/pci/pci_kvm_hook.c     | 11 +++++++++++
> > > >  drivers/vfio/pci/vfio_pci_zdev.c |  8 ++++++--
> > > >  5 files changed, 31 insertions(+), 17 deletions(-)
> > > >  create mode 100644 arch/s390/pci/pci_kvm_hook.c
> > > > 
> > > > diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
> > > > index f39092e0ceaa..8312ed9d1937 100644
> > > > --- a/arch/s390/include/asm/kvm_host.h
> > > > +++ b/arch/s390/include/asm/kvm_host.h
> > 
> > I added Janosch as second S390 KVM maintainer in case he wants to chime
> > in.
> > 
> > > > @@ -1038,16 +1038,11 @@ static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
> > > >  #define __KVM_HAVE_ARCH_VM_FREE
> > > >  void kvm_arch_free_vm(struct kvm *kvm);
> > > >  
> > > > -#ifdef CONFIG_VFIO_PCI_ZDEV_KVM
> > > > -int kvm_s390_pci_register_kvm(struct zpci_dev *zdev, struct kvm *kvm);
> > > > -void kvm_s390_pci_unregister_kvm(struct zpci_dev *zdev);
> > > > -#else
> > > > -static inline int kvm_s390_pci_register_kvm(struct zpci_dev *dev,
> > > > -					    struct kvm *kvm)
> > > > -{
> > > > -	return -EPERM;
> > > > -}
> > > > -static inline void kvm_s390_pci_unregister_kvm(struct zpci_dev *dev) {}
> > > > -#endif
> > > > +struct kvm_register_hook {
> > > 
> > > Nit: zpci_kvm_register_hook ?  Just to make it clear it's for zpci.
> > 
> > Hmm, I guess one could re-use the same struct for another such KVM
> > dependency but I lean towards the same thinking as Matt, for now this
> > is for zpci so stay specific we can always generalize later.
> 
> Yes, let's keep this zpci-specific. 
> 
> > Nit: For me hook and register together sound a bit redudant, maybe
> > "zpci_kvm_register"? Also question for Matt as a native speaker, should
> > it rather be "registration" when used as a noun here?
> > 
> 
> Maybe just drop the 'register'.  If there is a need for a 3rd function later, for example, it might not be related to registration.

Yes, that sounds good and makes sense so "zpci_kvm_hook".

> 
> e.g. struct kvm_zpci_hook {
>    ...
> };
> 
> extern struct kvm_zpci_hook zpci_kvm;
> 
---8<---
> > > 
> > > > diff --git a/arch/s390/pci/pci_kvm_hook.c b/arch/s390/pci/pci_kvm_hook.c
> > > > new file mode 100644
> > > > index 000000000000..9d8799b72dbf
> > > > --- /dev/null
> > > > +++ b/arch/s390/pci/pci_kvm_hook.c
> > > > @@ -0,0 +1,11 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > +/*
> > > > + * VFIO ZPCI devices support
> > > > + *
> > > > + * Copyright (C) IBM Corp. 2022.  All rights reserved.
> > > > + *	Author(s): Pierre Morel <pmorel@...ux.ibm.com>
> > > > + */
> > > > +#include <linux/kvm_host.h>
> > > > +
> > > > +struct kvm_register_hook kvm_pci_hook;
> > > > +EXPORT_SYMBOL_GPL(kvm_pci_hook);
> > > 
> > > Following the comments above, zpci_kvm_register_hook, kvm_zpci_hook ?
> > > 
> > > I'm not sure if this really needs to be in a separate file or if it could just go into arch/s390/pci.c with the zpci_aipb -- If going the route of a separate file, up to Niklas whether he wants this under the S390 PCI maintainership or added to the list for s390 vfio-pci like arch/kvm/pci* and vfio_pci_zdev.
> > 
> > I'm fine with a separate file, pci.c is long enough as it is. I also
> > don't have a problem with having it maintained as part of S390 PCI but
> > logically I think it does fall more under arch/kvm/pci* so one could
> > argue it should be added in the MAINTAINERS file in that section.
> > If you change the struct name as I proposed above I would probably go
> > with "pci_kvm_register.c"
> 
> OK, no problem with me for a separate file then, or maintaining said file.  But I guess not pci_kvm_register.c per my comments above

Yes, let's go with pci_kvm_hook.c then

>