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/
