From: Matthew Rosato <mjrosato@linux.ibm.com>
To: alex.williamson@redhat.com, cohuck@redhat.com
Cc: thuth@redhat.com, kvm@vger.kernel.org, pmorel@linux.ibm.com,
david@redhat.com, schnelle@linux.ibm.com, qemu-devel@nongnu.org,
pasic@linux.ibm.com, borntraeger@de.ibm.com,
qemu-s390x@nongnu.org, mst@redhat.com, pbonzini@redhat.com,
rth@twiddle.net
Subject: [PATCH v3 0/5] s390x/pci: Accomodate vfio DMA limiting
Date: Tue, 15 Sep 2020 15:14:38 -0400 [thread overview]
Message-ID: <1600197283-25274-1-git-send-email-mjrosato@linux.ibm.com> (raw)
Kernel commit 492855939bdb added a limit to the number of outstanding DMA
requests for a type1 vfio container. However, lazy unmapping in s390 can
in fact cause quite a large number of outstanding DMA requests to build up
prior to being purged, potentially the entire guest DMA space. This
results in unexpected 'VFIO_MAP_DMA failed: No space left on device'
conditions seen in QEMU.
This patchset adds support to qemu to retrieve the number of allowable DMA
requests via the VFIO_IOMMU_GET_INFO ioctl. The patches are separated into
vfio hits which add support for reading in VFIO_IOMMU_GET_INFO capability
chains and getting the per-container dma_avail value, and s390 hits to
track DMA usage on a per-container basis.
Associated kernel patch:
https://marc.info/?l=kvm&m=160019703922812&w=2
Changes from v2:
- Patch 1 (new): Added a placeholder linux-headers sync
- Patch 2: Re-arranged so that this patch that adds a shared routine for
finding info capabilities is first
- Patch 3: Adjusted vfio_get_info_dma_avail() logic to be able to return
true when the capability exists but the caller did not provide a buffer
on input.
- Patch 4 (new): Introduce hw/s390x/s390-pci-vfio.* to better-separate PCI
emulation code from code that interfaces with vfio
- Patch 4: s/s390_sync_dma_avail/s390_pci_update_dma_avail/ - Since it's
now moved into a different file it can't be static so I added '_pci'.
- Patch 4: Use g_autofree as suggested - drop the goto/out as a result
- Patch 4+5: Added asserts() in a few locations per suggestion
- Patch 5: lowercase inline function names
- Patch 5: fix dma_avail initialization in rpcit_service_call() and ensure
we still allow unmaps to call s390_pci_update_iotlb when dma_avail == 0
Matthew Rosato (5):
linux-headers: update against 5.9-rc5
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
hw/s390x/meson.build | 1 +
hw/s390x/s390-pci-bus.c | 56 ++++++++-
hw/s390x/s390-pci-bus.h | 9 ++
hw/s390x/s390-pci-inst.c | 34 ++++-
hw/s390x/s390-pci-inst.h | 3 +
hw/s390x/s390-pci-vfio.c | 54 ++++++++
hw/s390x/s390-pci-vfio.h | 17 +++
hw/vfio/common.c | 52 ++++++--
include/hw/vfio/vfio-common.h | 2 +
include/standard-headers/drm/drm_fourcc.h | 140 +++++++++++++++++++++
include/standard-headers/linux/ethtool.h | 87 +++++++++++++
include/standard-headers/linux/input-event-codes.h | 3 +-
include/standard-headers/linux/vhost_types.h | 11 ++
include/standard-headers/linux/virtio_9p.h | 4 +-
include/standard-headers/linux/virtio_blk.h | 26 ++--
include/standard-headers/linux/virtio_config.h | 8 +-
include/standard-headers/linux/virtio_console.h | 8 +-
include/standard-headers/linux/virtio_net.h | 6 +-
include/standard-headers/linux/virtio_scsi.h | 20 +--
linux-headers/asm-generic/unistd.h | 6 +-
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/kvm.h | 5 +
linux-headers/asm-powerpc/unistd_32.h | 1 +
linux-headers/asm-powerpc/unistd_64.h | 1 +
linux-headers/asm-s390/kvm.h | 7 +-
linux-headers/asm-s390/unistd_32.h | 1 +
linux-headers/asm-s390/unistd_64.h | 1 +
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 | 10 +-
linux-headers/linux/vfio.h | 18 ++-
linux-headers/linux/vhost.h | 2 +
35 files changed, 537 insertions(+), 62 deletions(-)
create mode 100644 hw/s390x/s390-pci-vfio.c
create mode 100644 hw/s390x/s390-pci-vfio.h
--
1.8.3.1
next reply other threads:[~2020-09-15 19:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-15 19:14 Matthew Rosato [this message]
2020-09-15 19:14 ` [PATCH v3 1/5] linux-headers: update against 5.9-rc5 Matthew Rosato
2020-09-15 19:14 ` [PATCH v3 2/5] vfio: Create shared routine for scanning info capabilities Matthew Rosato
2020-09-16 7:15 ` Philippe Mathieu-Daudé
2020-09-16 9:58 ` Cornelia Huck
2020-09-15 19:14 ` [PATCH v3 3/5] vfio: Find DMA available capability Matthew Rosato
2020-09-16 10:01 ` Cornelia Huck
2020-09-15 19:14 ` [PATCH v3 4/5] s390x/pci: Add routine to get the vfio dma available count Matthew Rosato
2020-09-16 7:21 ` Philippe Mathieu-Daudé
2020-09-16 10:27 ` Cornelia Huck
2020-09-16 12:55 ` Matthew Rosato
2020-09-17 9:59 ` Cornelia Huck
2020-09-15 19:14 ` [PATCH v3 5/5] s390x/pci: Honor DMA limits set by vfio Matthew Rosato
2020-09-16 11:05 ` Cornelia Huck
2020-09-16 12:58 ` Matthew Rosato
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=1600197283-25274-1-git-send-email-mjrosato@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).