Messages in this thread | | | Date | Tue, 28 Jun 2022 09:40:01 -0400 | Subject | Re: [PATCH v9 00/21] KVM: s390: enable zPCI for interpretive execution | From | 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/
| |