Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <66447089-921d-3665-963d-b9303b411f7f@linux.ibm.com>
Date:   Tue, 28 Jun 2022 16:02:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH v9 00/21] KVM: s390: enable zPCI for interpretive
 execution
Content-Language: en-US
To:     Matthew Rosato <mjrosato@linux.ibm.com>,
        linux-s390@vger.kernel.org, alex.williamson@redhat.com,
        pbonzini@redhat.com
Cc:     cohuck@redhat.com, schnelle@linux.ibm.com, farman@linux.ibm.com,
        pmorel@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
        gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
        svens@linux.ibm.com, frankja@linux.ibm.com, david@redhat.com,
        imbrenda@linux.ibm.com, vneethv@linux.ibm.com,
        oberpar@linux.ibm.com, freude@linux.ibm.com, thuth@redhat.com,
        pasic@linux.ibm.com, corbet@lwn.net, jgg@nvidia.com,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-doc@vger.kernel.org
References: <20220606203325.110625-1-mjrosato@linux.ibm.com>
 <f86e2e05-114a-cc9e-8f3a-96b36889063d@linux.ibm.com>
 <c98e7c10-272c-2bbb-6909-046d57d721d1@linux.ibm.com>
 <425d3030-94e2-efeb-60fd-08516443a06a@linux.ibm.com>
From:   Christian Borntraeger <borntraeger@linux.ibm.com>
In-Reply-To: <425d3030-94e2-efeb-60fd-08516443a06a@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Precedence: bulk


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?