Message ID | 1603726481-31824-1-git-send-email-mjrosato@linux.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | s390x/pci: s390-pci updates for kernel 5.10-rc1 | expand |
On Mon, 26 Oct 2020 11:34:28 -0400 Matthew Rosato <mjrosato@linux.ibm.com> wrote: > Combined set of patches that exploit vfio/s390-pci features available in > kernel 5.10-rc1. This patch set is a combination of > > [PATCH v4 0/5] s390x/pci: Accomodate vfio DMA limiting > > and > > [PATCH v3 00/10] Retrieve zPCI hardware information from VFIO > > with duplicate patches removed and a single header sync. All patches have > prior maintainer reviews except for: > > - Patch 1 (update-linux-headers change to add new file) That one has ;) > - Patch 2 (header sync against 5.10-rc1) I'm still unsure about the rdma/(q)atomic stuff -- had we reached any conclusion there? > - Patch 13 - contains a functional (debug) change; I switched from using > DPRINTFs to using trace events per Connie's request. > > > > Matthew Rosato (10): > update-linux-headers: Add vfio_zdev.h > linux-headers: update against 5.10-rc1 > s390x/pci: Move header files to include/hw/s390x > vfio: Create shared routine for scanning info capabilities > vfio: Find DMA available capability > s390x/pci: Add routine to get the vfio dma available count > s390x/pci: Honor DMA limits set by vfio > s390x/pci: clean up s390 PCI groups > vfio: Add routine for finding VFIO_DEVICE_GET_INFO capabilities > s390x/pci: get zPCI function info from host > > Pierre Morel (3): > s390x/pci: create a header dedicated to PCI CLP > s390x/pci: use a PCI Group structure > s390x/pci: use a PCI Function structure > > MAINTAINERS | 1 + > hw/s390x/meson.build | 1 + > hw/s390x/s390-pci-bus.c | 91 ++++++- > hw/s390x/s390-pci-inst.c | 78 ++++-- > hw/s390x/s390-pci-vfio.c | 276 +++++++++++++++++++++ > hw/s390x/s390-virtio-ccw.c | 2 +- > hw/s390x/trace-events | 6 + > hw/vfio/common.c | 62 ++++- > {hw => include/hw}/s390x/s390-pci-bus.h | 22 ++ > .../hw/s390x/s390-pci-clp.h | 123 +-------- > include/hw/s390x/s390-pci-inst.h | 119 +++++++++ > include/hw/s390x/s390-pci-vfio.h | 23 ++ > include/hw/vfio/vfio-common.h | 4 + > .../drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h | 14 +- > .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +- > include/standard-headers/linux/ethtool.h | 2 + > include/standard-headers/linux/fuse.h | 50 +++- > include/standard-headers/linux/input-event-codes.h | 4 + > include/standard-headers/linux/pci_regs.h | 6 +- > include/standard-headers/linux/virtio_fs.h | 3 + > include/standard-headers/linux/virtio_gpu.h | 19 ++ > include/standard-headers/linux/virtio_mmio.h | 11 + > include/standard-headers/linux/virtio_pci.h | 11 +- > linux-headers/asm-arm64/kvm.h | 25 ++ > linux-headers/asm-arm64/mman.h | 1 + > linux-headers/asm-generic/hugetlb_encode.h | 1 + > linux-headers/asm-generic/unistd.h | 18 +- > linux-headers/asm-mips/unistd_n32.h | 1 + > linux-headers/asm-mips/unistd_n64.h | 1 + > linux-headers/asm-mips/unistd_o32.h | 1 + > linux-headers/asm-powerpc/unistd_32.h | 1 + > linux-headers/asm-powerpc/unistd_64.h | 1 + > linux-headers/asm-s390/unistd_32.h | 1 + > linux-headers/asm-s390/unistd_64.h | 1 + > linux-headers/asm-x86/kvm.h | 20 ++ > linux-headers/asm-x86/unistd_32.h | 1 + > linux-headers/asm-x86/unistd_64.h | 1 + > linux-headers/asm-x86/unistd_x32.h | 1 + > linux-headers/linux/kvm.h | 19 ++ > linux-headers/linux/mman.h | 1 + > linux-headers/linux/vfio.h | 29 ++- > linux-headers/linux/vfio_zdev.h | 78 ++++++ > scripts/update-linux-headers.sh | 2 +- > 43 files changed, 961 insertions(+), 173 deletions(-) > create mode 100644 hw/s390x/s390-pci-vfio.c > rename {hw => include/hw}/s390x/s390-pci-bus.h (94%) > rename hw/s390x/s390-pci-inst.h => include/hw/s390x/s390-pci-clp.h (59%) > create mode 100644 include/hw/s390x/s390-pci-inst.h > create mode 100644 include/hw/s390x/s390-pci-vfio.h > create mode 100644 linux-headers/linux/vfio_zdev.h >
On 10/26/20 12:19 PM, Cornelia Huck wrote: > On Mon, 26 Oct 2020 11:34:28 -0400 > Matthew Rosato <mjrosato@linux.ibm.com> wrote: > >> Combined set of patches that exploit vfio/s390-pci features available in >> kernel 5.10-rc1. This patch set is a combination of >> >> [PATCH v4 0/5] s390x/pci: Accomodate vfio DMA limiting >> >> and >> >> [PATCH v3 00/10] Retrieve zPCI hardware information from VFIO >> >> with duplicate patches removed and a single header sync. All patches have >> prior maintainer reviews except for: >> >> - Patch 1 (update-linux-headers change to add new file) > > That one has ;) > >> - Patch 2 (header sync against 5.10-rc1) > > I'm still unsure about the rdma/(q)atomic stuff -- had we reached any > conclusion there? Ugh, I forgot about this... I had CC'd the associated maintainers a few times but never heard back from anyone on how to resolve this. Paolo said previously this stuff should not have been imported by a header sync in the first place (https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg00734.html), so I would guess that the proper fix is to stop importing the rdma stuff and (re)define it somewhere in QEMU. We could just drop the rmda file hit from this sync, but it's going to keep happening until the code is removed from the kernel header. > >> - Patch 13 - contains a functional (debug) change; I switched from using >> DPRINTFs to using trace events per Connie's request. >> >> >> >> Matthew Rosato (10): >> update-linux-headers: Add vfio_zdev.h >> linux-headers: update against 5.10-rc1 >> s390x/pci: Move header files to include/hw/s390x >> vfio: Create shared routine for scanning info capabilities >> vfio: Find DMA available capability >> s390x/pci: Add routine to get the vfio dma available count >> s390x/pci: Honor DMA limits set by vfio >> s390x/pci: clean up s390 PCI groups >> vfio: Add routine for finding VFIO_DEVICE_GET_INFO capabilities >> s390x/pci: get zPCI function info from host >> >> Pierre Morel (3): >> s390x/pci: create a header dedicated to PCI CLP >> s390x/pci: use a PCI Group structure >> s390x/pci: use a PCI Function structure >> >> MAINTAINERS | 1 + >> hw/s390x/meson.build | 1 + >> hw/s390x/s390-pci-bus.c | 91 ++++++- >> hw/s390x/s390-pci-inst.c | 78 ++++-- >> hw/s390x/s390-pci-vfio.c | 276 +++++++++++++++++++++ >> hw/s390x/s390-virtio-ccw.c | 2 +- >> hw/s390x/trace-events | 6 + >> hw/vfio/common.c | 62 ++++- >> {hw => include/hw}/s390x/s390-pci-bus.h | 22 ++ >> .../hw/s390x/s390-pci-clp.h | 123 +-------- >> include/hw/s390x/s390-pci-inst.h | 119 +++++++++ >> include/hw/s390x/s390-pci-vfio.h | 23 ++ >> include/hw/vfio/vfio-common.h | 4 + >> .../drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h | 14 +- >> .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +- >> include/standard-headers/linux/ethtool.h | 2 + >> include/standard-headers/linux/fuse.h | 50 +++- >> include/standard-headers/linux/input-event-codes.h | 4 + >> include/standard-headers/linux/pci_regs.h | 6 +- >> include/standard-headers/linux/virtio_fs.h | 3 + >> include/standard-headers/linux/virtio_gpu.h | 19 ++ >> include/standard-headers/linux/virtio_mmio.h | 11 + >> include/standard-headers/linux/virtio_pci.h | 11 +- >> linux-headers/asm-arm64/kvm.h | 25 ++ >> linux-headers/asm-arm64/mman.h | 1 + >> linux-headers/asm-generic/hugetlb_encode.h | 1 + >> linux-headers/asm-generic/unistd.h | 18 +- >> linux-headers/asm-mips/unistd_n32.h | 1 + >> linux-headers/asm-mips/unistd_n64.h | 1 + >> linux-headers/asm-mips/unistd_o32.h | 1 + >> linux-headers/asm-powerpc/unistd_32.h | 1 + >> linux-headers/asm-powerpc/unistd_64.h | 1 + >> linux-headers/asm-s390/unistd_32.h | 1 + >> linux-headers/asm-s390/unistd_64.h | 1 + >> linux-headers/asm-x86/kvm.h | 20 ++ >> linux-headers/asm-x86/unistd_32.h | 1 + >> linux-headers/asm-x86/unistd_64.h | 1 + >> linux-headers/asm-x86/unistd_x32.h | 1 + >> linux-headers/linux/kvm.h | 19 ++ >> linux-headers/linux/mman.h | 1 + >> linux-headers/linux/vfio.h | 29 ++- >> linux-headers/linux/vfio_zdev.h | 78 ++++++ >> scripts/update-linux-headers.sh | 2 +- >> 43 files changed, 961 insertions(+), 173 deletions(-) >> create mode 100644 hw/s390x/s390-pci-vfio.c >> rename {hw => include/hw}/s390x/s390-pci-bus.h (94%) >> rename hw/s390x/s390-pci-inst.h => include/hw/s390x/s390-pci-clp.h (59%) >> create mode 100644 include/hw/s390x/s390-pci-inst.h >> create mode 100644 include/hw/s390x/s390-pci-vfio.h >> create mode 100644 linux-headers/linux/vfio_zdev.h >> >
On Mon, 26 Oct 2020 17:19:47 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > On Mon, 26 Oct 2020 11:34:28 -0400 > Matthew Rosato <mjrosato@linux.ibm.com> wrote: > > > Combined set of patches that exploit vfio/s390-pci features available in > > kernel 5.10-rc1. This patch set is a combination of > > > > [PATCH v4 0/5] s390x/pci: Accomodate vfio DMA limiting > > > > and > > > > [PATCH v3 00/10] Retrieve zPCI hardware information from VFIO > > > > with duplicate patches removed and a single header sync. All patches have > > prior maintainer reviews except for: > > > > - Patch 1 (update-linux-headers change to add new file) > > That one has ;) > > > - Patch 2 (header sync against 5.10-rc1) > > I'm still unsure about the rdma/(q)atomic stuff -- had we reached any > conclusion there? > > > - Patch 13 - contains a functional (debug) change; I switched from using > > DPRINTFs to using trace events per Connie's request. Looks good. I think that should go through the vfio tree, in case there are collisions with the migration stuff? (The s390x queue is currently empty.) > > > > > > > > Matthew Rosato (10): > > update-linux-headers: Add vfio_zdev.h > > linux-headers: update against 5.10-rc1 > > s390x/pci: Move header files to include/hw/s390x > > vfio: Create shared routine for scanning info capabilities > > vfio: Find DMA available capability > > s390x/pci: Add routine to get the vfio dma available count > > s390x/pci: Honor DMA limits set by vfio > > s390x/pci: clean up s390 PCI groups > > vfio: Add routine for finding VFIO_DEVICE_GET_INFO capabilities > > s390x/pci: get zPCI function info from host > > > > Pierre Morel (3): > > s390x/pci: create a header dedicated to PCI CLP > > s390x/pci: use a PCI Group structure > > s390x/pci: use a PCI Function structure > > > > MAINTAINERS | 1 + > > hw/s390x/meson.build | 1 + > > hw/s390x/s390-pci-bus.c | 91 ++++++- > > hw/s390x/s390-pci-inst.c | 78 ++++-- > > hw/s390x/s390-pci-vfio.c | 276 +++++++++++++++++++++ > > hw/s390x/s390-virtio-ccw.c | 2 +- > > hw/s390x/trace-events | 6 + > > hw/vfio/common.c | 62 ++++- > > {hw => include/hw}/s390x/s390-pci-bus.h | 22 ++ > > .../hw/s390x/s390-pci-clp.h | 123 +-------- > > include/hw/s390x/s390-pci-inst.h | 119 +++++++++ > > include/hw/s390x/s390-pci-vfio.h | 23 ++ > > include/hw/vfio/vfio-common.h | 4 + > > .../drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h | 14 +- > > .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +- > > include/standard-headers/linux/ethtool.h | 2 + > > include/standard-headers/linux/fuse.h | 50 +++- > > include/standard-headers/linux/input-event-codes.h | 4 + > > include/standard-headers/linux/pci_regs.h | 6 +- > > include/standard-headers/linux/virtio_fs.h | 3 + > > include/standard-headers/linux/virtio_gpu.h | 19 ++ > > include/standard-headers/linux/virtio_mmio.h | 11 + > > include/standard-headers/linux/virtio_pci.h | 11 +- > > linux-headers/asm-arm64/kvm.h | 25 ++ > > linux-headers/asm-arm64/mman.h | 1 + > > linux-headers/asm-generic/hugetlb_encode.h | 1 + > > linux-headers/asm-generic/unistd.h | 18 +- > > linux-headers/asm-mips/unistd_n32.h | 1 + > > linux-headers/asm-mips/unistd_n64.h | 1 + > > linux-headers/asm-mips/unistd_o32.h | 1 + > > linux-headers/asm-powerpc/unistd_32.h | 1 + > > linux-headers/asm-powerpc/unistd_64.h | 1 + > > linux-headers/asm-s390/unistd_32.h | 1 + > > linux-headers/asm-s390/unistd_64.h | 1 + > > linux-headers/asm-x86/kvm.h | 20 ++ > > linux-headers/asm-x86/unistd_32.h | 1 + > > linux-headers/asm-x86/unistd_64.h | 1 + > > linux-headers/asm-x86/unistd_x32.h | 1 + > > linux-headers/linux/kvm.h | 19 ++ > > linux-headers/linux/mman.h | 1 + > > linux-headers/linux/vfio.h | 29 ++- > > linux-headers/linux/vfio_zdev.h | 78 ++++++ > > scripts/update-linux-headers.sh | 2 +- > > 43 files changed, 961 insertions(+), 173 deletions(-) > > create mode 100644 hw/s390x/s390-pci-vfio.c > > rename {hw => include/hw}/s390x/s390-pci-bus.h (94%) > > rename hw/s390x/s390-pci-inst.h => include/hw/s390x/s390-pci-clp.h (59%) > > create mode 100644 include/hw/s390x/s390-pci-inst.h > > create mode 100644 include/hw/s390x/s390-pci-vfio.h > > create mode 100644 linux-headers/linux/vfio_zdev.h > > >
On Mon, 26 Oct 2020 12:38:45 -0400 Matthew Rosato <mjrosato@linux.ibm.com> wrote: > On 10/26/20 12:19 PM, Cornelia Huck wrote: > > On Mon, 26 Oct 2020 11:34:28 -0400 > > Matthew Rosato <mjrosato@linux.ibm.com> wrote: > > > >> Combined set of patches that exploit vfio/s390-pci features available in > >> kernel 5.10-rc1. This patch set is a combination of > >> > >> [PATCH v4 0/5] s390x/pci: Accomodate vfio DMA limiting > >> > >> and > >> > >> [PATCH v3 00/10] Retrieve zPCI hardware information from VFIO > >> > >> with duplicate patches removed and a single header sync. All patches have > >> prior maintainer reviews except for: > >> > >> - Patch 1 (update-linux-headers change to add new file) > > > > That one has ;) > > > >> - Patch 2 (header sync against 5.10-rc1) > > > > I'm still unsure about the rdma/(q)atomic stuff -- had we reached any > > conclusion there? > > Ugh, I forgot about this... I had CC'd the associated maintainers a few > times but never heard back from anyone on how to resolve this. > > Paolo said previously this stuff should not have been imported by a > header sync in the first place > (https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg00734.html), > so I would guess that the proper fix is to stop importing the rdma stuff > and (re)define it somewhere in QEMU. I think so. > > We could just drop the rmda file hit from this sync, but it's going to > keep happening until the code is removed from the kernel header. Yeah. It's unfortunate that 5.10-rc1 and the soft freeze are so close together :( > > > > >> - Patch 13 - contains a functional (debug) change; I switched from using > >> DPRINTFs to using trace events per Connie's request. > >> > >> > >> > >> Matthew Rosato (10): > >> update-linux-headers: Add vfio_zdev.h > >> linux-headers: update against 5.10-rc1 > >> s390x/pci: Move header files to include/hw/s390x > >> vfio: Create shared routine for scanning info capabilities > >> vfio: Find DMA available capability > >> s390x/pci: Add routine to get the vfio dma available count > >> s390x/pci: Honor DMA limits set by vfio > >> s390x/pci: clean up s390 PCI groups > >> vfio: Add routine for finding VFIO_DEVICE_GET_INFO capabilities > >> s390x/pci: get zPCI function info from host > >> > >> Pierre Morel (3): > >> s390x/pci: create a header dedicated to PCI CLP > >> s390x/pci: use a PCI Group structure > >> s390x/pci: use a PCI Function structure > >> > >> MAINTAINERS | 1 + > >> hw/s390x/meson.build | 1 + > >> hw/s390x/s390-pci-bus.c | 91 ++++++- > >> hw/s390x/s390-pci-inst.c | 78 ++++-- > >> hw/s390x/s390-pci-vfio.c | 276 +++++++++++++++++++++ > >> hw/s390x/s390-virtio-ccw.c | 2 +- > >> hw/s390x/trace-events | 6 + > >> hw/vfio/common.c | 62 ++++- > >> {hw => include/hw}/s390x/s390-pci-bus.h | 22 ++ > >> .../hw/s390x/s390-pci-clp.h | 123 +-------- > >> include/hw/s390x/s390-pci-inst.h | 119 +++++++++ > >> include/hw/s390x/s390-pci-vfio.h | 23 ++ > >> include/hw/vfio/vfio-common.h | 4 + > >> .../drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h | 14 +- > >> .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h | 2 +- > >> include/standard-headers/linux/ethtool.h | 2 + > >> include/standard-headers/linux/fuse.h | 50 +++- > >> include/standard-headers/linux/input-event-codes.h | 4 + > >> include/standard-headers/linux/pci_regs.h | 6 +- > >> include/standard-headers/linux/virtio_fs.h | 3 + > >> include/standard-headers/linux/virtio_gpu.h | 19 ++ > >> include/standard-headers/linux/virtio_mmio.h | 11 + > >> include/standard-headers/linux/virtio_pci.h | 11 +- > >> linux-headers/asm-arm64/kvm.h | 25 ++ > >> linux-headers/asm-arm64/mman.h | 1 + > >> linux-headers/asm-generic/hugetlb_encode.h | 1 + > >> linux-headers/asm-generic/unistd.h | 18 +- > >> linux-headers/asm-mips/unistd_n32.h | 1 + > >> linux-headers/asm-mips/unistd_n64.h | 1 + > >> linux-headers/asm-mips/unistd_o32.h | 1 + > >> linux-headers/asm-powerpc/unistd_32.h | 1 + > >> linux-headers/asm-powerpc/unistd_64.h | 1 + > >> linux-headers/asm-s390/unistd_32.h | 1 + > >> linux-headers/asm-s390/unistd_64.h | 1 + > >> linux-headers/asm-x86/kvm.h | 20 ++ > >> linux-headers/asm-x86/unistd_32.h | 1 + > >> linux-headers/asm-x86/unistd_64.h | 1 + > >> linux-headers/asm-x86/unistd_x32.h | 1 + > >> linux-headers/linux/kvm.h | 19 ++ > >> linux-headers/linux/mman.h | 1 + > >> linux-headers/linux/vfio.h | 29 ++- > >> linux-headers/linux/vfio_zdev.h | 78 ++++++ > >> scripts/update-linux-headers.sh | 2 +- > >> 43 files changed, 961 insertions(+), 173 deletions(-) > >> create mode 100644 hw/s390x/s390-pci-vfio.c > >> rename {hw => include/hw}/s390x/s390-pci-bus.h (94%) > >> rename hw/s390x/s390-pci-inst.h => include/hw/s390x/s390-pci-clp.h (59%) > >> create mode 100644 include/hw/s390x/s390-pci-inst.h > >> create mode 100644 include/hw/s390x/s390-pci-vfio.h > >> create mode 100644 linux-headers/linux/vfio_zdev.h > >> > > >
On Mon, 26 Oct 2020 17:41:24 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > On Mon, 26 Oct 2020 17:19:47 +0100 > Cornelia Huck <cohuck@redhat.com> wrote: > > > On Mon, 26 Oct 2020 11:34:28 -0400 > > Matthew Rosato <mjrosato@linux.ibm.com> wrote: > > > > > Combined set of patches that exploit vfio/s390-pci features available in > > > kernel 5.10-rc1. This patch set is a combination of > > > > > > [PATCH v4 0/5] s390x/pci: Accomodate vfio DMA limiting > > > > > > and > > > > > > [PATCH v3 00/10] Retrieve zPCI hardware information from VFIO > > > > > > with duplicate patches removed and a single header sync. All patches have > > > prior maintainer reviews except for: > > > > > > - Patch 1 (update-linux-headers change to add new file) > > > > That one has ;) > > > > > - Patch 2 (header sync against 5.10-rc1) > > > > I'm still unsure about the rdma/(q)atomic stuff -- had we reached any > > conclusion there? > > > > > - Patch 13 - contains a functional (debug) change; I switched from using > > > DPRINTFs to using trace events per Connie's request. > > Looks good. > > I think that should go through the vfio tree, in case there are > collisions with the migration stuff? > > (The s390x queue is currently empty.) Patches appear to apply cleanly on top of the migration series, but I can take it if preferred. Thanks, Alex