linux-kernel - Re: [PATCH v9 00/21] KVM: s390: enable zPCI for interpretive execution

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Jun 2022 10:49:58 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Matthew Rosato <mjrosato@...ux.ibm.com>
Cc:     Christian Borntraeger <borntraeger@...ux.ibm.com>,
        linux-s390@...r.kernel.org, alex.williamson@...hat.com,
        cohuck@...hat.com, schnelle@...ux.ibm.com, farman@...ux.ibm.com,
        pmorel@...ux.ibm.com, hca@...ux.ibm.com, gor@...ux.ibm.com,
        gerald.schaefer@...ux.ibm.com, agordeev@...ux.ibm.com,
        svens@...ux.ibm.com, frankja@...ux.ibm.com, david@...hat.com,
        imbrenda@...ux.ibm.com, vneethv@...ux.ibm.com,
        oberpar@...ux.ibm.com, freude@...ux.ibm.com, thuth@...hat.com,
        pasic@...ux.ibm.com, pbonzini@...hat.com, corbet@....net,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH v9 00/21] KVM: s390: enable zPCI for interpretive
 execution

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