On Tue, Jun 28, 2022 at 09:40:01AM -0400, Matthew Rosato wrote: > 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. You should use a branch based on vfio-next and send a Git PR to Christian and Alex Jason
