From: Pierre Morel <pmorel@linux.ibm.com> To: Matthew Rosato <mjrosato@linux.ibm.com>, qemu-s390x@nongnu.org, alex.williamson@redhat.com Cc: schnelle@linux.ibm.com, cohuck@redhat.com, thuth@redhat.com, farman@linux.ibm.com, richard.henderson@linaro.org, david@redhat.com, pasic@linux.ibm.com, borntraeger@linux.ibm.com, mst@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org Subject: Re: [PATCH v5 7/9] s390x/pci: enable adapter event notification for interpreted devices Date: Mon, 2 May 2022 09:48:56 +0200 [thread overview] Message-ID: <d14625f4-d648-05d9-38aa-a5ad7e0c9cf5@linux.ibm.com> (raw) In-Reply-To: <9a171204-6d71-ee1d-d8bd-cd4eac91c3d5@linux.ibm.com> On 4/22/22 14:10, Matthew Rosato wrote: > On 4/22/22 5:39 AM, Pierre Morel wrote: >> >> >> On 4/4/22 20:17, Matthew Rosato wrote: >>> Use the associated kvm ioctl operation to enable adapter event >>> notification >>> and forwarding for devices when requested. This feature will be set up >>> with or without firmware assist based upon the 'forwarding_assist' >>> setting. >>> >>> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> >>> --- >>> hw/s390x/s390-pci-bus.c | 20 ++++++++++++++--- >>> hw/s390x/s390-pci-inst.c | 40 +++++++++++++++++++++++++++++++-- >>> hw/s390x/s390-pci-kvm.c | 30 +++++++++++++++++++++++++ >>> include/hw/s390x/s390-pci-bus.h | 1 + >>> include/hw/s390x/s390-pci-kvm.h | 14 ++++++++++++ >>> 5 files changed, 100 insertions(+), 5 deletions(-) >>> >>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >>> index 9c02d31250..47918d2ce9 100644 >>> --- a/hw/s390x/s390-pci-bus.c >>> +++ b/hw/s390x/s390-pci-bus.c >>> @@ -190,7 +190,10 @@ void s390_pci_sclp_deconfigure(SCCB *sccb) >>> rc = SCLP_RC_NO_ACTION_REQUIRED; >>> break; >>> default: >>> - if (pbdev->summary_ind) { >>> + if (pbdev->interp && (pbdev->fh & FH_MASK_ENABLE)) { >>> + /* Interpreted devices were using interrupt forwarding */ >>> + s390_pci_kvm_aif_disable(pbdev); >> >> Same remark as for the kernel part. >> The VFIO device is already initialized and the action is on this >> device, Shouldn't we use the VFIO device interface instead of the KVM >> interface? >> > > I don't necessarily disagree, but in v3 of the kernel series I was told > not to use VFIO ioctls to accomplish tasks that are unique to KVM (e.g. > AEN interpretation) and to instead use a KVM ioctl. > > VFIO_DEVICE_SET_IRQS won't work as-is for reasons described in the > kernel series (e.g. we don't see any of the config space notifiers > because of instruction interpretation) -- as far as I can figure we > could add our own s390 code to QEMU to issue VFIO_DEVICE_SET_IRQS > directly for an interpreted device, but I think would also need > s390-specific changes to VFIO_DEVICE_SET_IRQS accommodate this (e.g. > maybe something like a VFIO_IRQ_SET_DATA_S390AEN where we can then > specify the aen information in vfio_irq_set.data -- or something else I Hi, yes this in VFIO_DEVICE_SET_IRQS is what I think should be done. > haven't though of yet) -- I can try to look at this some more and see if > I get a good idea. I understood that the demand was concerning the IOMMU but I may be wrong. For my opinion, the handling of AEN is not specific to KVM but specific to the device, for example the code should be the same if Z ever decide to use XEN or another hypervizor, except for the GISA part but this part is already implemented in KVM in a way it can be used from a device like in VFIO AP. @Alex, what do you think? Regards, Pierre -- Pierre Morel IBM Lab Boeblingen
WARNING: multiple messages have this Message-ID (diff)
From: Pierre Morel <pmorel@linux.ibm.com> To: Matthew Rosato <mjrosato@linux.ibm.com>, qemu-s390x@nongnu.org, alex.williamson@redhat.com Cc: thuth@redhat.com, kvm@vger.kernel.org, david@redhat.com, cohuck@redhat.com, richard.henderson@linaro.org, farman@linux.ibm.com, qemu-devel@nongnu.org, pasic@linux.ibm.com, mst@redhat.com, schnelle@linux.ibm.com, pbonzini@redhat.com, borntraeger@linux.ibm.com Subject: Re: [PATCH v5 7/9] s390x/pci: enable adapter event notification for interpreted devices Date: Mon, 2 May 2022 09:48:56 +0200 [thread overview] Message-ID: <d14625f4-d648-05d9-38aa-a5ad7e0c9cf5@linux.ibm.com> (raw) In-Reply-To: <9a171204-6d71-ee1d-d8bd-cd4eac91c3d5@linux.ibm.com> On 4/22/22 14:10, Matthew Rosato wrote: > On 4/22/22 5:39 AM, Pierre Morel wrote: >> >> >> On 4/4/22 20:17, Matthew Rosato wrote: >>> Use the associated kvm ioctl operation to enable adapter event >>> notification >>> and forwarding for devices when requested. This feature will be set up >>> with or without firmware assist based upon the 'forwarding_assist' >>> setting. >>> >>> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> >>> --- >>> hw/s390x/s390-pci-bus.c | 20 ++++++++++++++--- >>> hw/s390x/s390-pci-inst.c | 40 +++++++++++++++++++++++++++++++-- >>> hw/s390x/s390-pci-kvm.c | 30 +++++++++++++++++++++++++ >>> include/hw/s390x/s390-pci-bus.h | 1 + >>> include/hw/s390x/s390-pci-kvm.h | 14 ++++++++++++ >>> 5 files changed, 100 insertions(+), 5 deletions(-) >>> >>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >>> index 9c02d31250..47918d2ce9 100644 >>> --- a/hw/s390x/s390-pci-bus.c >>> +++ b/hw/s390x/s390-pci-bus.c >>> @@ -190,7 +190,10 @@ void s390_pci_sclp_deconfigure(SCCB *sccb) >>> rc = SCLP_RC_NO_ACTION_REQUIRED; >>> break; >>> default: >>> - if (pbdev->summary_ind) { >>> + if (pbdev->interp && (pbdev->fh & FH_MASK_ENABLE)) { >>> + /* Interpreted devices were using interrupt forwarding */ >>> + s390_pci_kvm_aif_disable(pbdev); >> >> Same remark as for the kernel part. >> The VFIO device is already initialized and the action is on this >> device, Shouldn't we use the VFIO device interface instead of the KVM >> interface? >> > > I don't necessarily disagree, but in v3 of the kernel series I was told > not to use VFIO ioctls to accomplish tasks that are unique to KVM (e.g. > AEN interpretation) and to instead use a KVM ioctl. > > VFIO_DEVICE_SET_IRQS won't work as-is for reasons described in the > kernel series (e.g. we don't see any of the config space notifiers > because of instruction interpretation) -- as far as I can figure we > could add our own s390 code to QEMU to issue VFIO_DEVICE_SET_IRQS > directly for an interpreted device, but I think would also need > s390-specific changes to VFIO_DEVICE_SET_IRQS accommodate this (e.g. > maybe something like a VFIO_IRQ_SET_DATA_S390AEN where we can then > specify the aen information in vfio_irq_set.data -- or something else I Hi, yes this in VFIO_DEVICE_SET_IRQS is what I think should be done. > haven't though of yet) -- I can try to look at this some more and see if > I get a good idea. I understood that the demand was concerning the IOMMU but I may be wrong. For my opinion, the handling of AEN is not specific to KVM but specific to the device, for example the code should be the same if Z ever decide to use XEN or another hypervizor, except for the GISA part but this part is already implemented in KVM in a way it can be used from a device like in VFIO AP. @Alex, what do you think? Regards, Pierre -- Pierre Morel IBM Lab Boeblingen
next prev parent reply other threads:[~2022-05-02 7:45 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-04 18:17 [PATCH v5 0/9] s390x/pci: zPCI interpretation support Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-04 18:17 ` [PATCH v5 1/9] Update linux headers Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-04 18:17 ` [PATCH v5 2/9] vfio: tolerate migration protocol v1 uapi renames Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-12 15:50 ` Pierre Morel 2022-04-12 15:50 ` Pierre Morel 2022-04-12 16:07 ` Matthew Rosato 2022-04-12 16:07 ` Matthew Rosato 2022-04-19 15:44 ` Pierre Morel 2022-04-04 18:17 ` [PATCH v5 3/9] target/s390x: add zpci-interp to cpu models Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-05-18 8:01 ` Thomas Huth 2022-05-18 8:02 ` Thomas Huth 2022-05-18 8:05 ` Thomas Huth 2022-04-04 18:17 ` [PATCH v5 4/9] s390x/pci: add routine to get host function handle from CLP info Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-19 19:15 ` Pierre Morel 2022-04-19 19:15 ` Pierre Morel 2022-05-18 8:13 ` Thomas Huth 2022-04-04 18:17 ` [PATCH v5 5/9] s390x/pci: enable for load/store intepretation Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-19 19:47 ` Pierre Morel 2022-04-19 19:47 ` Pierre Morel 2022-04-20 15:12 ` Matthew Rosato 2022-04-20 15:12 ` Matthew Rosato 2022-04-22 9:27 ` Pierre Morel 2022-04-22 9:27 ` Pierre Morel 2022-04-04 18:17 ` [PATCH v5 6/9] s390x/pci: don't fence interpreted devices without MSI-X Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-04 18:17 ` [PATCH v5 7/9] s390x/pci: enable adapter event notification for interpreted devices Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-22 9:39 ` Pierre Morel 2022-04-22 9:39 ` Pierre Morel 2022-04-22 12:10 ` Matthew Rosato 2022-04-22 12:10 ` Matthew Rosato 2022-05-02 7:48 ` Pierre Morel [this message] 2022-05-02 7:48 ` Pierre Morel 2022-05-02 9:19 ` Niklas Schnelle 2022-05-02 9:19 ` Niklas Schnelle 2022-05-02 11:30 ` Pierre Morel 2022-05-02 11:30 ` Pierre Morel 2022-05-02 19:57 ` Matthew Rosato 2022-05-03 14:53 ` Pierre Morel 2022-05-04 14:20 ` Matthew Rosato 2022-04-04 18:17 ` [PATCH v5 8/9] s390x/pci: let intercept devices have separate PCI groups Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-04 18:17 ` [PATCH v5 9/9] s390x/pci: reflect proper maxstbl for groups of interpreted devices Matthew Rosato 2022-04-04 18:17 ` Matthew Rosato 2022-04-19 19:49 ` Pierre Morel 2022-04-19 19:49 ` Pierre Morel 2022-04-22 9:43 ` Pierre Morel 2022-04-22 9:43 ` Pierre Morel 2022-05-06 9:03 ` Pierre Morel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=d14625f4-d648-05d9-38aa-a5ad7e0c9cf5@linux.ibm.com \ --to=pmorel@linux.ibm.com \ --cc=alex.williamson@redhat.com \ --cc=borntraeger@linux.ibm.com \ --cc=cohuck@redhat.com \ --cc=david@redhat.com \ --cc=farman@linux.ibm.com \ --cc=kvm@vger.kernel.org \ --cc=mjrosato@linux.ibm.com \ --cc=mst@redhat.com \ --cc=pasic@linux.ibm.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=qemu-s390x@nongnu.org \ --cc=richard.henderson@linaro.org \ --cc=schnelle@linux.ibm.com \ --cc=thuth@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.