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?
