Messages in this thread | | | Date | Tue, 28 Jun 2022 16:02:32 +0200 | Subject | Re: [PATCH v9 00/21] KVM: s390: enable zPCI for interpretive execution | From | Christian Borntraeger <> |
| |
Am 28.06.22 um 15:40 schrieb Matthew Rosato: > On 6/28/22 8:35 AM, Christian Borntraeger wrote: >> Am 27.06.22 um 22:57 schrieb Matthew Rosato: >>> On 6/6/22 4:33 PM, Matthew Rosato wrote: >>>> Enable interpretive execution of zPCI instructions + adapter interruption >>>> forwarding for s390x KVM vfio-pci. This is done by triggering a routine >>>> when the VFIO group is associated with the KVM guest, transmitting to >>>> firmware a special token (GISA designation) to enable that specific guest >>>> for interpretive execution on that zPCI device. Load/store interpreation >>>> enablement is then controlled by userspace (based upon whether or not a >>>> SHM bit is placed in the virtual function handle). Adapter Event >>>> Notification interpretation is controlled from userspace via a new KVM >>>> ioctl. >>>> >>>> By allowing intepretation of zPCI instructions and firmware delivery of >>>> interrupts to guests, we can reduce the frequency of guest SIE exits for >>>> zPCI. >>>> >>>> From the perspective of guest configuration, you passthrough zPCI devices >>>> in the same manner as before, with intepretation support being used by >>>> default if available in kernel+qemu. >>>> >>>> Will follow up with a link the most recent QEMU series. >>>> >>>> Changelog v8->v9: >>>> - Rebase on top of 5.19-rc1, adjust ioctl and capability defines >>>> - s/kzdev = 0/kzdev = NULL/ (Alex) >>>> - rename vfio_pci_zdev_open to vfio_pci_zdev_open_device (Jason) >>>> - rename vfio_pci_zdev_release to vfio_pci_zdev_close_device (Jason) >>>> - make vfio_pci_zdev_close_device return void, instead WARN_ON or ignore >>>> errors in lower level function (kvm_s390_pci_unregister_kvm) (Jason) >>>> - remove notifier accidentally left in struct zpci_dev + associated >>>> include statment (Jason) >>>> - Remove patch 'KVM: s390: introduce CPU feature for zPCI Interpretation' >>>> based on discussion in QEMU thread. >>>> >>> >>> Ping -- I'm hoping this can make the next merge window, but there are still 2 patches left without any review tag (16 & 17). >> >> Yes, I will queue this (as is). Ideally you would rebase this on top of kvm/next but I can also do while applying. >> Let me know if you want to respin with the Nits from Pierre. > > Ah, sorry -- I assume you mean Paolo's kvm/next? I tried now and see some conflicts with the ioctl patch. > > Why don't I rebase on top of kvm/next along with these couple of changes from Pierre and send this as a v10 for you to queue. > > While at it, there's one other issue to be aware of -- There will also be small merge conflicts with a patch that just hit vfio-next, "vfio: de-extern-ify function prototypes" - My series already avoids adding externs to new prototypes, but adjacent code changes will cause a conflict with patches 10 and 17. > > Not sure what the best way to proceed there is. > > https://lore.kernel.org/kvm/165471414407.203056.474032786990662279.stgit@omen/
I think Linus can sort out if the conflicts are trivial. As an alternative Alex could carry these patches, but then we have a merge conflict between him and KVM. Alex/Paolo, shall I do a topic branch that you both can merge?
| |