lkml.org 
[lkml]   [2022]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v9 00/21] KVM: s390: enable zPCI for interpretive execution
From
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/

\
 
 \ /
  Last update: 2022-06-28 15:43    [W:0.060 / U:34.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site