From: Pierre Morel <pmorel@linux.ibm.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>
Cc: rdunlap@infradead.org, linux-kernel@vger.kernel.org,
lkp@intel.com, borntraeger@linux.ibm.com, farman@linux.ibm.com,
linux-s390@vger.kernel.org, kvm@vger.kernel.org,
gor@linux.ibm.com, hca@linux.ibm.com, schnelle@linux.ibm.com
Subject: Re: [PATCH] KVM: s390: pci: Hook to access KVM lowlevel from VFIO
Date: Thu, 18 Aug 2022 16:06:04 +0200 [thread overview]
Message-ID: <955ef95a-df7c-9e66-43ec-4495a79f51d3@linux.ibm.com> (raw)
In-Reply-To: <f797373e-c420-718a-443d-ae98ea0368c7@linux.ibm.com>
On 8/18/22 15:33, 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'.
OK
>
>>
>> Reported-by: Randy Dunlap <rdunlap@infradead.org>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>> Fixes: 09340b2fca007 ("KVM: s390: pci: add routines to start/stop inter..")
>> Cc: <stable@vger.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
>> @@ -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.
OK
>
>> + int (*kvm_register)(void *opaque, struct kvm *kvm);
>> + void (*kvm_unregister)(void *opaque);
>> +};
>> +
>> +extern struct kvm_register_hook kvm_pci_hook;
>
> Nit: kvm_zpci_hook ?
OK too,
>
>>
>> #endif
>> diff --git a/arch/s390/kvm/pci.c b/arch/s390/kvm/pci.c
>> index 4946fb7757d6..e173fce64c4f 100644
>> --- a/arch/s390/kvm/pci.c
>> +++ b/arch/s390/kvm/pci.c
>> @@ -431,8 +431,9 @@ static void kvm_s390_pci_dev_release(struct zpci_dev *zdev)
>> * available, enable them and let userspace indicate whether or not they will
>> * be used (specify SHM bit to disable).
>> */
>> -int kvm_s390_pci_register_kvm(struct zpci_dev *zdev, struct kvm *kvm)
>> +static int kvm_s390_pci_register_kvm(void *opaque, struct kvm *kvm)
>> {
>> + struct zpci_dev *zdev = opaque;
>> int rc;
>>
>> if (!zdev)
>> @@ -510,10 +511,10 @@ int kvm_s390_pci_register_kvm(struct zpci_dev *zdev, struct kvm *kvm)
>> kvm_put_kvm(kvm);
>> return rc;
>> }
>> -EXPORT_SYMBOL_GPL(kvm_s390_pci_register_kvm);
>>
>> -void kvm_s390_pci_unregister_kvm(struct zpci_dev *zdev)
>> +static void kvm_s390_pci_unregister_kvm(void *opaque)
>> {
>> + struct zpci_dev *zdev = opaque;
>> struct kvm *kvm;
>>
>> if (!zdev)
>> @@ -566,7 +567,6 @@ void kvm_s390_pci_unregister_kvm(struct zpci_dev *zdev)
>>
>> kvm_put_kvm(kvm);
>> }
>> -EXPORT_SYMBOL_GPL(kvm_s390_pci_unregister_kvm);
>>
>> void kvm_s390_pci_init_list(struct kvm *kvm)
>> {
>> @@ -678,6 +678,8 @@ int kvm_s390_pci_init(void)
>>
>> spin_lock_init(&aift->gait_lock);
>> mutex_init(&aift->aift_lock);
>> + kvm_pci_hook.kvm_register = kvm_s390_pci_register_kvm;
>> + kvm_pci_hook.kvm_unregister = kvm_s390_pci_unregister_kvm;
>>
>> return 0;
>> }
>> diff --git a/arch/s390/pci/Makefile b/arch/s390/pci/Makefile
>> index bf557a1b789c..c02dbfb415d9 100644
>> --- a/arch/s390/pci/Makefile
>> +++ b/arch/s390/pci/Makefile
>> @@ -7,3 +7,5 @@ obj-$(CONFIG_PCI) += pci.o pci_irq.o pci_dma.o pci_clp.o pci_sysfs.o \
>> pci_event.o pci_debug.o pci_insn.o pci_mmio.o \
>> pci_bus.o
>> obj-$(CONFIG_PCI_IOV) += pci_iov.o
>> +
>> +obj-y += pci_kvm_hook.o
>
> I guess it doesn't harm anything to add this unconditionally, but I think it would also be OK to just include this in the CONFIG_PCI list - vfio_pci_zdev and arch/s390/kvm/pci all rely on CONFIG_PCI via CONFIG_VFIO_PCI_ZDEV_KVM which implies PCI via VFIO_PCI.
Right,CONFIG_PCI is a bool so we can put the hook in arch/s390/pci/pci.c
and use a defined(CONFIG_PCI) to protect the initialization inside KVM.
>
>> 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@linux.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 ?
OK
>
> 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.
agreed no need for a separate file, it is much better.
>
>> diff --git a/drivers/vfio/pci/vfio_pci_zdev.c b/drivers/vfio/pci/vfio_pci_zdev.c
>> index e163aa9f6144..3b7a707e2fe5 100644
>> --- a/drivers/vfio/pci/vfio_pci_zdev.c
>> +++ b/drivers/vfio/pci/vfio_pci_zdev.c
>> @@ -151,7 +151,10 @@ int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)
>> if (!vdev->vdev.kvm)
>> return 0;
>>
>> - return kvm_s390_pci_register_kvm(zdev, vdev->vdev.kvm);
>> + if (kvm_pci_hook.kvm_register)
>> + return kvm_pci_hook.kvm_register(zdev, vdev->vdev.kvm);
>> +
>> + return -ENOENT;
>> }
>>
>> void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)
>> @@ -161,5 +164,6 @@ void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)
>> if (!zdev || !vdev->vdev.kvm)
>> return;
>>
>> - kvm_s390_pci_unregister_kvm(zdev);
>> + if (kvm_pci_hook.kvm_unregister)
>> + return kvm_pci_hook.kvm_unregister(zdev);
>
> No need for the return here, this is a void function calling a void function.
right.
>
>
> Overall, this looks good to me and survives a series of compile and device passthrough tests on my end, just a matter of a few of these minor comments above. Thanks for tackling this Pierre!
>
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
next prev parent reply other threads:[~2022-08-18 14:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-14 21:51 [PATCH] vfio-pci/zdev: require KVM to be built-in Randy Dunlap
2022-08-15 9:43 ` Pierre Morel
2022-08-16 6:04 ` Randy Dunlap
2022-08-16 7:55 ` Pierre Morel
2022-08-16 13:47 ` Pierre Morel
2022-08-16 18:06 ` Randy Dunlap
2022-08-16 19:46 ` Matthew Rosato
2022-08-16 20:22 ` Pierre Morel
2022-08-16 20:28 ` [PATCH] KVM: s390: pci: VFIO_PCI ZDEV configuration fix Pierre Morel
2022-08-16 22:15 ` Matthew Rosato
2022-08-17 7:10 ` Pierre Morel
2022-08-18 10:23 ` [PATCH] KVM: s390: pci: Hook to access KVM lowlevel from VFIO Pierre Morel
2022-08-18 13:33 ` Matthew Rosato
2022-08-18 14:06 ` Pierre Morel [this message]
2022-08-18 14:20 ` Niklas Schnelle
2022-08-18 15:13 ` Matthew Rosato
2022-08-18 15:22 ` Niklas Schnelle
-- strict thread matches above, loose matches on Subject: below --
2022-08-18 16:46 Pierre Morel
2022-08-18 20:38 ` Matthew Rosato
2022-08-18 20:54 ` Pierre Morel
2022-08-19 7:14 ` Niklas Schnelle
2022-08-19 8:44 ` Pierre Morel
2022-08-19 10:42 ` Niklas Schnelle
2022-08-19 11:42 ` Pierre Morel
2022-08-19 11:49 ` Niklas Schnelle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=955ef95a-df7c-9e66-43ec-4495a79f51d3@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=farman@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mjrosato@linux.ibm.com \
--cc=rdunlap@infradead.org \
--cc=schnelle@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox