Re: [PATCH 8/9] vfio/pci: use x86 naming instead of igd

On 2/11/21 10:47 AM, Max Gurtovoy wrote: On 2/2/2021 7:10 PM, Jason Gunthorpe wrote: On Tue, Feb 02, 2021 at 05:06:59PM +0100, Cornelia Huck wrote: On the other side, we have the zdev support, which both requires s390 and applies to any pci device on s390. Is there a reason why

Re: [PATCH 8/9] vfio/pci: use x86 naming instead of igd

On 2/1/21 12:14 PM, Cornelia Huck wrote: On Mon, 1 Feb 2021 16:28:27 + Max Gurtovoy wrote: This patch doesn't change any logic but only align to the concept of vfio_pci_core extensions. Extensions that are related to a platform and not to a specific vendor of PCI devices should be part of

Re: [PATCH 5/9] vfio-pci/zdev: remove unused vdev argument

On 2/1/21 11:28 AM, Max Gurtovoy wrote: Zdev static functions does not use vdev argument. Remove it. Signed-off-by: Max Gurtovoy Huh. I must have dropped the use of vdev somewhere during review versions. Thanks! Reviewed-by: Matthew Rosato @Alex/@Connie This one is just a cleanup

Re: [PATCH 6/9] vfio-pci/zdev: fix possible segmentation fault issue

_INFO") Reviewed-by: Cornelia Huck I think this should go in independently of this series. > Agreed, makes sense to me -- thanks for finding. Reviewed-by: Matthew Rosato --- drivers/vfio/pci/vfio_pci_zdev.c | 4 1 file changed, 4 insertions(+)

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

On 1/27/21 12:45 PM, Cornelia Huck wrote: On Wed, 27 Jan 2021 08:53:05 -0700 Alex Williamson wrote: On Wed, 27 Jan 2021 09:23:04 -0500 Matthew Rosato wrote: On 1/26/21 6:18 PM, Alex Williamson wrote: On Mon, 25 Jan 2021 09:40:38 -0500 Matthew Rosato wrote: On 1/22/21 6:48 PM, Alex

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

On 1/26/21 6:18 PM, Alex Williamson wrote: On Mon, 25 Jan 2021 09:40:38 -0500 Matthew Rosato wrote: On 1/22/21 6:48 PM, Alex Williamson wrote: On Tue, 19 Jan 2021 15:02:30 -0500 Matthew Rosato wrote: Some s390 PCI devices (e.g. ISM) perform I/O operations that have very specific

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

On 1/22/21 6:48 PM, Alex Williamson wrote: On Tue, 19 Jan 2021 15:02:30 -0500 Matthew Rosato wrote: Some s390 PCI devices (e.g. ISM) perform I/O operations that have very specific requirements in terms of alignment as well as the patterns in which the data is read/written. Allowing

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

On 1/25/21 10:42 AM, Cornelia Huck wrote: On Mon, 25 Jan 2021 09:40:38 -0500 Matthew Rosato wrote: On 1/22/21 6:48 PM, Alex Williamson wrote: On Tue, 19 Jan 2021 15:02:30 -0500 Matthew Rosato wrote: Some s390 PCI devices (e.g. ISM) perform I/O operations that have very specific

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

On 1/21/21 5:01 AM, Niklas Schnelle wrote: On 1/19/21 9:02 PM, Matthew Rosato wrote: Some s390 PCI devices (e.g. ISM) perform I/O operations that have very specific requirements in terms of alignment as well as the patterns in which the data is read/written. Allowing these to proceed through

Re: [PATCH 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

On 1/20/21 4:02 AM, Pierre Morel wrote: On 1/19/21 9:02 PM, Matthew Rosato wrote: Today, ISM devices are completely disallowed for vfio-pci passthrough as QEMU will reject the device due to an (inappropriate) MSI-X check. However, in an effort to enable ISM device passthrough, I realized

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

On 1/20/21 12:28 PM, Niklas Schnelle wrote: On 1/20/21 6:10 PM, Matthew Rosato wrote: On 1/20/21 8:21 AM, Niklas Schnelle wrote: On 1/19/21 9:02 PM, Matthew Rosato wrote: Some s390 PCI devices (e.g. ISM) perform I/O operations that have very .. snip ... + +static size_t

Re: [PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

On 1/20/21 8:21 AM, Niklas Schnelle wrote: On 1/19/21 9:02 PM, Matthew Rosato wrote: Some s390 PCI devices (e.g. ISM) perform I/O operations that have very .. snip ... + +static size_t vfio_pci_zdev_io_rw(struct vfio_pci_device *vdev, + char __user *buf

Re: [PATCH 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

On 1/19/21 3:02 PM, Matthew Rosato wrote: Today, ISM devices are completely disallowed for vfio-pci passthrough as QEMU will reject the device due to an (inappropriate) MSI-X check. However, in an effort to enable ISM device passthrough, I realized that the manner in which ISM performs block

[PATCH 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

devices. Signed-off-by: Matthew Rosato --- drivers/vfio/pci/vfio_pci.c | 8 ++ drivers/vfio/pci/vfio_pci_private.h | 6 ++ drivers/vfio/pci/vfio_pci_zdev.c| 158 include/uapi/linux/vfio.h | 4 + include/uapi/linux/vfio_zdev.h

[PATCH 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

in memory briefly in order to execute the requested PCI instruction. Changes from RFC -> v1: - No functional changes, just minor commentary changes -- Re-posting along with updated QEMU set. Matthew Rosato (4): s390/pci: track alignment/length strictness for zpci_dev vfio-pci/zdev: P

[PATCH 1/4] s390/pci: track alignment/length strictness for zpci_dev

Some zpci device types (e.g., ISM) follow different rules for length and alignment of pci instructions. Recognize this and keep track of it in the zpci_dev. Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle Reviewed-by: Pierre Morel --- arch/s390/include/asm/pci.h | 3 ++- arch

[PATCH 3/4] s390/pci: Get hardware-reported max store block length

We'll need to know this information for vfio passthrough. Signed-off-by: Matthew Rosato Reviewed-by: Pierre Morel --- arch/s390/include/asm/pci.h | 1 + arch/s390/include/asm/pci_clp.h | 3 ++- arch/s390/pci/pci_clp.c | 1 + 3 files changed, 4 insertions(+), 1 deletion(-) diff

[PATCH 2/4] vfio-pci/zdev: Pass the relaxed alignment flag

Use an additional bit of the VFIO_DEVICE_INFO_CAP_ZPCI_GROUP flags field to pass whether or not the associated device supports relaxed length and alignment for some I/O operations. Signed-off-by: Matthew Rosato Acked-by: Niklas Schnelle Reviewed-by: Pierre Morel --- drivers/vfio/pci

Re: [PATCH v13 11/15] s390/vfio-ap: implement in-use callback for vfio_ap driver

On 1/11/21 8:20 PM, Halil Pasic wrote: On Tue, 22 Dec 2020 20:16:02 -0500 Tony Krowiak wrote: Let's implement the callback to indicate when an APQN is in use by the vfio_ap device driver. The callback is invoked whenever a change to the apmask or aqmask would result in one or more queue

Re: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

On 12/17/20 7:59 AM, Cornelia Huck wrote: On Fri, 11 Dec 2020 10:04:43 -0500 Matthew Rosato wrote: On 12/11/20 10:01 AM, Matthew Rosato wrote: On 12/11/20 9:35 AM, Cornelia Huck wrote: Let me summarize this to make sure I understand this new region correctly: - some devices may have

Re: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

On 12/11/20 10:01 AM, Matthew Rosato wrote: On 12/11/20 9:35 AM, Cornelia Huck wrote: On Thu, 10 Dec 2020 10:51:23 -0500 Matthew Rosato wrote: On 12/10/20 7:33 AM, Cornelia Huck wrote: On Wed,  9 Dec 2020 15:27:46 -0500 Matthew Rosato wrote: Today, ISM devices are completely disallowed

Re: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

On 12/11/20 9:35 AM, Cornelia Huck wrote: On Thu, 10 Dec 2020 10:51:23 -0500 Matthew Rosato wrote: On 12/10/20 7:33 AM, Cornelia Huck wrote: On Wed, 9 Dec 2020 15:27:46 -0500 Matthew Rosato wrote: Today, ISM devices are completely disallowed for vfio-pci passthrough as QEMU

Re: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

On 12/10/20 7:33 AM, Cornelia Huck wrote: On Wed, 9 Dec 2020 15:27:46 -0500 Matthew Rosato wrote: Today, ISM devices are completely disallowed for vfio-pci passthrough as QEMU will reject the device due to an (inappropriate) MSI-X check. However, in an effort to enable ISM device passthrough

Re: [RFC 1/4] s390/pci: track alignment/length strictness for zpci_dev

On 12/10/20 5:33 AM, Cornelia Huck wrote: On Wed, 9 Dec 2020 15:27:47 -0500 Matthew Rosato wrote: Some zpci device types (e.g., ISM) follow different rules for length and alignment of pci instructions. Recognize this and keep track of it in the zpci_dev. Signed-off-by: Matthew Rosato

Re: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

On 12/9/20 3:27 PM, Matthew Rosato wrote: Today, ISM devices are completely disallowed for vfio-pci passthrough as QEMU will reject the device due to an (inappropriate) MSI-X check. However, in an effort to enable ISM device passthrough, I realized that the manner in which ISM performs block

[RFC 4/4] vfio-pci/zdev: Introduce the zPCI I/O vfio region

devices. Signed-off-by: Matthew Rosato --- drivers/vfio/pci/vfio_pci.c | 8 ++ drivers/vfio/pci/vfio_pci_private.h | 6 ++ drivers/vfio/pci/vfio_pci_zdev.c| 158 include/uapi/linux/vfio.h | 4 + include/uapi/linux/vfio_zdev.h

[RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

in memory briefly in order to execute the requested PCI instruction. Matthew Rosato (4): s390/pci: track alignment/length strictness for zpci_dev vfio-pci/zdev: Pass the relaxed alignment flag s390/pci: Get hardware-reported max store block length vfio-pci/zdev: Introduce the zPCI I/O vfio

[RFC 1/4] s390/pci: track alignment/length strictness for zpci_dev

Some zpci device types (e.g., ISM) follow different rules for length and alignment of pci instructions. Recognize this and keep track of it in the zpci_dev. Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle Reviewed-by: Pierre Morel --- arch/s390/include/asm/pci.h | 3 ++- arch

[RFC 3/4] s390/pci: Get hardware-reported max store block length

We'll need to know this information for vfio passthrough. Signed-off-by: Matthew Rosato Reviewed-by: Pierre Morel --- arch/s390/include/asm/pci.h | 1 + arch/s390/include/asm/pci_clp.h | 3 ++- arch/s390/pci/pci_clp.c | 1 + 3 files changed, 4 insertions(+), 1 deletion(-) diff

[RFC 2/4] vfio-pci/zdev: Pass the relaxed alignment flag

Use an additional bit of the VFIO_DEVICE_INFO_CAP_ZPCI_GROUP flags field to pass whether or not the associated device supports relaxed length and alignment for some I/O operations. Signed-off-by: Matthew Rosato Acked-by: Niklas Schnelle Reviewed-by: Pierre Morel --- drivers/vfio/pci

Re: [PATCH v3 0/5] Pass zPCI hardware information via VFIO

On 10/7/20 2:56 PM, Matthew Rosato wrote: This patchset provides a means by which hardware information about the underlying PCI device can be passed up to userspace (ie, QEMU) so that this hardware information can be used rather than previously hard-coded assumptions. The VFIO_DEVICE_GET_INFO

[PATCH v3 5/5] MAINTAINERS: Add entry for s390 vfio-pci

Add myself to cover s390-specific items related to vfio-pci. Signed-off-by: Matthew Rosato Acked-by: Cornelia Huck --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9a54806..a0e8d14 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15170,6

[PATCH v3 4/5] vfio-pci/zdev: Add zPCI capabilities to VFIO_DEVICE_GET_INFO

Morel. Signed-off-by: Matthew Rosato --- drivers/vfio/pci/Kconfig| 13 drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/vfio_pci.c | 37 ++ drivers/vfio/pci/vfio_pci_private.h | 12 +++ drivers/vfio/pci/vfio_pci_zdev.c| 143

[PATCH v3 3/5] vfio: Introduce capability definitions for VFIO_DEVICE_GET_INFO

Allow the VFIO_DEVICE_GET_INFO ioctl to include a capability chain. Add a flag indicating capability chain support, and introduce the definitions for the first set of capabilities which are specified to s390 zPCI devices. Signed-off-by: Matthew Rosato --- include/uapi/linux/vfio.h | 11

[PATCH v3 0/5] Pass zPCI hardware information via VFIO

. Matthew Rosato (5): s390/pci: stash version in the zpci_dev s390/pci: track whether util_str is valid in the zpci_dev vfio: Introduce capability definitions for VFIO_DEVICE_GET_INFO vfio-pci/zdev: Add zPCI capabilities to VFIO_DEVICE_GET_INFO MAINTAINERS: Add entry for s390 vfio-pci

[PATCH v3 1/5] s390/pci: stash version in the zpci_dev

In preparation for passing the info on to vfio-pci devices, stash the supported PCI version for the target device in the zpci_dev. Signed-off-by: Matthew Rosato Acked-by: Niklas Schnelle Acked-by: Christian Borntraeger Acked-by: Cornelia Huck --- arch/s390/include/asm/pci.h | 1 + arch/s390

[PATCH v3 2/5] s390/pci: track whether util_str is valid in the zpci_dev

We'll need to keep track of whether or not the byte string in util_str is valid and thus needs to be passed to a vfio-pci passthrough device. Signed-off-by: Matthew Rosato Acked-by: Niklas Schnelle Acked-by: Christian Borntraeger Acked-by: Cornelia Huck --- arch/s390/include/asm/pci.h | 3

Re: [PATCH v2 3/5] vfio-pci/zdev: define the vfio_zdev header

On 10/5/20 12:01 PM, Cornelia Huck wrote: On Mon, 5 Oct 2020 09:52:25 -0400 Matthew Rosato wrote: On 10/2/20 5:44 PM, Alex Williamson wrote: Can you discuss why a region with embedded capability chain is a better solution than extending the VFIO_DEVICE_GET_INFO ioctl to support

Re: [PATCH v2 3/5] vfio-pci/zdev: define the vfio_zdev header

On 10/2/20 5:44 PM, Alex Williamson wrote: On Fri, 2 Oct 2020 16:00:42 -0400 Matthew Rosato wrote: We define a new device region in vfio.h to be able to get the ZPCI CLP information by reading this region from userspace. We create a new file, vfio_zdev.h to define the structure of the new

Re: [PATCH v2 0/5] Pass zPCI hardware information via VFIO

On 10/2/20 4:00 PM, Matthew Rosato wrote: This patchset provides a means by which hardware information about the underlying PCI device can be passed up to userspace (ie, QEMU) so that this hardware information can be used rather than previously hard-coded assumptions. A new VFIO region type

[PATCH v2 2/5] s390/pci: track whether util_str is valid in the zpci_dev

We'll need to keep track of whether or not the byte string in util_str is valid and thus needs to be passed to a vfio-pci passthrough device. Signed-off-by: Matthew Rosato Acked-by: Niklas Schnelle Acked-by: Christian Borntraeger --- arch/s390/include/asm/pci.h | 3 ++- arch/s390/pci

[PATCH v2 1/5] s390/pci: stash version in the zpci_dev

In preparation for passing the info on to vfio-pci devices, stash the supported PCI version for the target device in the zpci_dev. Signed-off-by: Matthew Rosato Acked-by: Niklas Schnelle Acked-by: Christian Borntraeger Acked-by: Cornelia Huck --- arch/s390/include/asm/pci.h | 1 + arch/s390

[PATCH v2 4/5] vfio-pci/zdev: use a device region to retrieve zPCI information

. Signed-off-by: Matthew Rosato --- drivers/vfio/pci/Kconfig| 13 ++ drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/vfio_pci.c | 8 ++ drivers/vfio/pci/vfio_pci_private.h | 10 ++ drivers/vfio/pci/vfio_pci_zdev.c| 242 5

[PATCH v2 3/5] vfio-pci/zdev: define the vfio_zdev header

We define a new device region in vfio.h to be able to get the ZPCI CLP information by reading this region from userspace. We create a new file, vfio_zdev.h to define the structure of the new region defined in vfio.h Signed-off-by: Matthew Rosato --- include/uapi/linux/vfio.h | 5

[PATCH v2 5/5] MAINTAINERS: Add entry for s390 vfio-pci

Add myself to cover s390-specific items related to vfio-pci. Signed-off-by: Matthew Rosato --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 190c7fa..389c4ad 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15162,6 +15162,14 @@ F

[PATCH v2 0/5] Pass zPCI hardware information via VFIO

configuration entry. Changes from v1: - Added ACKs (thanks!) - Patch 2: Minor change:s/util_avail/util_str_avail/ per Niklas - Patch 3: removed __packed - Patch 3: rework various descriptions / comment blocks - New patch: MAINTAINERS hit to cover new files. Matthew Rosato (5): s390/pci: stash

Re: [PATCH v5 3/3] vfio/pci: Decouple PCI_COMMAND_MEMORY bit checks from is_virtfn

On 9/22/20 12:40 PM, Alex Williamson wrote: On Mon, 21 Sep 2020 08:43:29 -0400 Matthew Rosato wrote: On 9/10/20 10:59 AM, Matthew Rosato wrote: While it is true that devices with is_virtfn=1 will have a Memory Space Enable bit that is hard-wired to 0, this is not the only case where we see

Re: [PATCH 2/4] s390/pci: track whether util_str is valid in the zpci_dev

On 9/21/20 5:41 AM, Niklas Schnelle wrote: Hi Matthew, On 9/19/20 5:28 PM, Matthew Rosato wrote: We'll need to keep track of whether or not the byte string in util_str is valid and thus needs to be passed to a vfio-pci passthrough device. Signed-off-by: Matthew Rosato --- arch/s390/include

Re: [PATCH 4/4] vfio-pci/zdev: use a device region to retrieve zPCI information

On 9/22/20 7:22 AM, Cornelia Huck wrote: On Sat, 19 Sep 2020 11:28:38 -0400 Matthew Rosato wrote: Define a new configuration entry VFIO_PCI_ZDEV for VFIO/PCI. When this s390-only feature is configured we initialize a new device region, VFIO_REGION_SUBTYPE_IBM_ZPCI_CLP, to hold information

Re: [PATCH 3/4] vfio-pci/zdev: define the vfio_zdev header

On 9/22/20 6:54 AM, Cornelia Huck wrote: On Sat, 19 Sep 2020 11:28:37 -0400 Matthew Rosato wrote: We define a new device region in vfio.h to be able to get the ZPCI CLP information by reading this region from userspace. We create a new file, vfio_zdev.h to define the structure of the new

Re: [PATCH 1/4] s390/pci: stash version in the zpci_dev

On 9/21/20 11:01 AM, Cornelia Huck wrote: On Sat, 19 Sep 2020 11:28:35 -0400 Matthew Rosato wrote: In preparation for passing the info on to vfio-pci devices, stash the supported PCI version for the target device in the zpci_dev. Hm, what kind of version is that? The version of the zPCI

Re: [PATCH v5 3/3] vfio/pci: Decouple PCI_COMMAND_MEMORY bit checks from is_virtfn

On 9/10/20 10:59 AM, Matthew Rosato wrote: While it is true that devices with is_virtfn=1 will have a Memory Space Enable bit that is hard-wired to 0, this is not the only case where we see this behavior -- For example some bare-metal hypervisors lack Memory Space Enable bit emulation

Re: [PATCH 0/4] Pass zPCI hardware information via VFIO

On 9/19/20 11:28 AM, Matthew Rosato wrote: This patchset provides a means by which hardware information about the underlying PCI device can be passed up to userspace (ie, QEMU) so that this hardware information can be used rather than previously hard-coded assumptions. A new VFIO region type

[PATCH 4/4] vfio-pci/zdev: use a device region to retrieve zPCI information

. Signed-off-by: Matthew Rosato --- drivers/vfio/pci/Kconfig| 13 ++ drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/vfio_pci.c | 8 ++ drivers/vfio/pci/vfio_pci_private.h | 10 ++ drivers/vfio/pci/vfio_pci_zdev.c| 242 5

[PATCH 2/4] s390/pci: track whether util_str is valid in the zpci_dev

We'll need to keep track of whether or not the byte string in util_str is valid and thus needs to be passed to a vfio-pci passthrough device. Signed-off-by: Matthew Rosato --- arch/s390/include/asm/pci.h | 3 ++- arch/s390/pci/pci_clp.c | 1 + 2 files changed, 3 insertions(+), 1 deletion

[PATCH 3/4] vfio-pci/zdev: define the vfio_zdev header

We define a new device region in vfio.h to be able to get the ZPCI CLP information by reading this region from userspace. We create a new file, vfio_zdev.h to define the structure of the new region defined in vfio.h Signed-off-by: Matthew Rosato --- include/uapi/linux/vfio.h | 5

[PATCH 1/4] s390/pci: stash version in the zpci_dev

In preparation for passing the info on to vfio-pci devices, stash the supported PCI version for the target device in the zpci_dev. Signed-off-by: Matthew Rosato --- arch/s390/include/asm/pci.h | 1 + arch/s390/pci/pci_clp.c | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/s390

[PATCH 0/4] Pass zPCI hardware information via VFIO

configuration entry. Matthew Rosato (4): s390/pci: stash version in the zpci_dev s390/pci: track whether util_str is valid in the zpci_dev vfio-pci/zdev: define the vfio_zdev header vfio-pci/zdev: use a device region to retrieve zPCI information arch/s390/include/asm/pci.h | 4

Re: [PATCH v3] vfio iommu: Add dma available capability

On 9/15/20 3:05 PM, Matthew Rosato wrote: Commit 492855939bdb ("vfio/type1: Limit DMA mappings per container") added a limit to the number of concurrent DMA requests for a vfio container. However, lazy unmapping in s390 can in fact cause quite a large number of outstanding DMA request

[PATCH v3] vfio iommu: Add dma available capability

A mappings to userspace via the IOMMU info chain so that userspace can take appropriate mitigation. Signed-off-by: Matthew Rosato --- drivers/vfio/vfio_iommu_type1.c | 17 + include/uapi/linux/vfio.h | 15 +++ 2 files changed, 32 insertions(+) diff --git a/dr

[PATCH v3] vfio iommu: Add dma available capability

QEMU would collect this information and use it in s390 PCI support to tap the guest on the shoulder before overrunning the vfio limit. Changes from v2: - Typos / fixed stale comment block Matthew Rosato (1): vfio iommu: Add dma available capability drivers/vfio/vfio_iommu_ty

Re: [PATCH v2] vfio iommu: Add dma available capability

On 9/15/20 5:44 AM, Cornelia Huck wrote: On Mon, 14 Sep 2020 18:25:31 -0400 Matthew Rosato wrote: Commit 492855939bdb ("vfio/type1: Limit DMA mappings per container") added the ability to limit the number of memory backed DMA mappings. However on s390x, when lazy mapping is in u

Re: [PATCH v2] vfio iommu: Add dma available capability

On 9/14/20 6:25 PM, Matthew Rosato wrote: Commit 492855939bdb ("vfio/type1: Limit DMA mappings per container") added a limit to the number of concurrent DMA requests for a vfio container. However, lazy unmapping in s390 can in fact cause quite a large number of outstanding DMA request

[PATCH v2] vfio iommu: Add dma available capability

QEMU would collect this information and use it in s390 PCI support to tap the guest on the shoulder before overrunning the vfio limit. Changes from v1: - Report dma_avail instead of the limit, which might not have been accurate anyway - Text/naming changes throughout due to the above Matthew

[PATCH v2] vfio iommu: Add dma available capability

A mappings to userspace via the IOMMU info chain so that userspace can take appropriate mitigation. Signed-off-by: Matthew Rosato --- drivers/vfio/vfio_iommu_type1.c | 17 + include/uapi/linux/vfio.h | 16 2 files changed, 33 insertions(+) diff --git a/dr

Re: [PATCH] vfio iommu: Add dma limit capability

On 9/11/20 1:09 PM, Alex Williamson wrote: On Fri, 11 Sep 2020 12:44:03 -0400 Matthew Rosato wrote: Commit 492855939bdb ("vfio/type1: Limit DMA mappings per container") added the ability to limit the number of memory backed DMA mappings. However on s390x, when lazy mapping is in u

Re: [PATCH] vfio iommu: Add dma limit capability

On 9/11/20 12:44 PM, Matthew Rosato wrote: Commit 492855939bdb ("vfio/type1: Limit DMA mappings per container") added a limit to the number of concurrent DMA requests for a vfio container. However, lazy unmapping in s390 can in fact cause quite a large number of outstanding DMA request

[PATCH] vfio iommu: Add dma limit capability

IOMMU info chain so that userspace can take appropriate mitigation. Signed-off-by: Matthew Rosato --- drivers/vfio/vfio_iommu_type1.c | 17 + include/uapi/linux/vfio.h | 16 2 files changed, 33 insertions(+) diff --git a/drivers/vfio/vfio_iommu_type1.c b/dr

[PATCH] vfio iommu: Add dma limit capability

on and use it in s390 PCI support to tap the guest on the shoulder before overrunning the vfio limit. Matthew Rosato (1): vfio iommu: Add dma limit capability drivers/vfio/vfio_iommu_type1.c | 17 + include/uapi/linux/vfio.h | 16 2 files changed, 33

[PATCH v5 1/3] PCI/IOV: Mark VFs as not implementing PCI_COMMAND_MEMORY

For VFs, the Memory Space Enable bit in the Command Register is hard-wired to 0. Add a new bit to signify devices where the Command Register Memory Space Enable bit does not control the device's response to MMIO accesses. Signed-off-by: Matthew Rosato --- drivers/pci/iov.c | 1 + include

[PATCH v5 2/3] s390/pci: Mark all VFs as not implementing PCI_COMMAND_MEMORY

these devices do not implement PCI_COMMAND_MEMORY. Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle Reviewed-by: Pierre Morel --- arch/s390/pci/pci_bus.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/s390/pci/pci_bus.c b/arch/s390/pci/pci_bus.c index 5967f30

[PATCH v5 0/3] vfio/pci: Restore MMIO access for s390 detached VFs

//marc.info/?l=linux-pci=159856041930022=2 Matthew Rosato (3): PCI/IOV: Mark VFs as not implementing PCI_COMMAND_MEMORY s390/pci: Mark all VFs as not implementing PCI_COMMAND_MEMORY vfio/pci: Decouple PCI_COMMAND_MEMORY bit checks from is_virtfn arch/s390/pci/pci_bus.c|

[PATCH v5 3/3] vfio/pci: Decouple PCI_COMMAND_MEMORY bit checks from is_virtfn

this by instead checking for the newly-added no_command_memory bit which directly denotes the need for PCI_COMMAND_MEMORY emulation in vfio. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle

Re: [PATCH v4 1/3] PCI/IOV: Mark VFs as not implementing MSE bit

On 9/3/20 12:41 PM, Bjorn Helgaas wrote: On Wed, Sep 02, 2020 at 03:46:34PM -0400, Matthew Rosato wrote: Per the PCIe spec, VFs cannot implement the MSE bit AKA PCI_COMMAND_MEMORY, and it must be hard-wired to 0. Use a dev_flags bit to signify this requirement. This approach seems sensible

[PATCH v4 3/3] vfio/pci: Decouple MSE bit checks from is_virtfn

PCI_DEV_FLAGS_FORCE_COMMAND_MEM flag which directly denotes the need for MSE bit emulation in vfio. Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle --- drivers/vfio/pci/vfio_pci_config.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/drivers

[PATCH v4 2/3] s390/pci: Mark all VFs as not implementing MSE bit

not implement the MSE bit. Signed-off-by: Matthew Rosato Reviewed-by: Niklas Schnelle --- arch/s390/pci/pci_bus.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/s390/pci/pci_bus.c b/arch/s390/pci/pci_bus.c index 5967f30..73789a7 100644 --- a/arch/s390/pci/pci_bus.c +++ b

[PATCH v4 0/3] vfio/pci: Restore MMIO access for s390 detached VFs

ev_flags bit instead of is_virtfn [1]: https://marc.info/?l=linux-pci=159856041930022=2 Matthew Rosato (3): PCI/IOV: Mark VFs as not implementing MSE bit s390/pci: Mark all VFs as not implementing MSE bit vfio/pci: Decouple MSE bit checks from is_virtfn arch/s390/pci/pci_bus.c| 5 +++-

[PATCH v4 1/3] PCI/IOV: Mark VFs as not implementing MSE bit

Per the PCIe spec, VFs cannot implement the MSE bit AKA PCI_COMMAND_MEMORY, and it must be hard-wired to 0. Use a dev_flags bit to signify this requirement. Signed-off-by: Matthew Rosato --- drivers/pci/iov.c | 1 + include/linux/pci.h | 2 ++ 2 files changed, 3 insertions(+) diff --git

Re: [PATCH v3] PCI: Introduce flag for detached virtual functions

le/Restore/ as this functionality had been working until the mem bit enforcement was added to vfio via abafbc551fdd. On Thu, Aug 13, 2020 at 11:40:43AM -0400, Matthew Rosato wrote: s390x has the notion of providing VFs to the kernel in a manner where the associated PF is inaccessible other than vi

Re: [PATCH v3] PCI: Introduce flag for detached virtual functions

On 8/13/20 11:40 AM, Matthew Rosato wrote: s390x has the notion of providing VFs to the kernel in a manner where the associated PF is inaccessible other than via firmware. These are not treated as typical VFs and access to them is emulated by underlying firmware which can still access the PF

[PATCH v3] PCI: Introduce flag for detached virtual functions

block MMIO access on disabled memory") Signed-off-by: Matthew Rosato --- arch/s390/pci/pci_bus.c| 13 + drivers/vfio/pci/vfio_pci_config.c | 8 include/linux/pci.h| 4 3 files changed, 21 insertions(+), 4 deletions(-) diff --git a/arc

[PATCH v3] PCI: Identifying detached virtual functions

mation to vfio-pci so that it knows to also accept the lack of PCI_COMMAND_MEMORY for these sorts of devices. For now the bit is only set for s390x but other architectures could opt in to it as well if needed. Matthew Rosato (1): PCI: Introduce flag for detached virtual functions arch/s390

Re: [PATCH v2] PCI: Introduce flag for detached virtual functions

On 8/13/20 8:34 AM, Niklas Schnelle wrote: On 8/13/20 12:40 PM, Niklas Schnelle wrote: On 8/13/20 11:59 AM, Oliver O'Halloran wrote: On Thu, Aug 13, 2020 at 7:00 PM Niklas Schnelle wrote: On 8/13/20 3:55 AM, Oliver O'Halloran wrote: On Thu, Aug 13, 2020 at 5:21 AM Matthew Rosato

Re: [PATCH v2] PCI: Introduce flag for detached virtual functions

On 8/12/20 4:32 PM, Alex Williamson wrote: On Wed, 12 Aug 2020 15:21:11 -0400 Matthew Rosato wrote: s390x has the notion of providing VFs to the kernel in a manner where the associated PF is inaccessible other than via firmware. These are not treated as typical VFs and access to them

[PATCH v2] PCI: Identifying detached virtual functions

is information to vfio-pci so that it knows to also accept the lack of PCI_COMMAND_MEMORY for these sorts of devices. For now the bit is only set for s390x but other architectures could opt in to it as well if needed. Matthew Rosato (1): PCI: Introduce flag for detached virtual functions arch/

[PATCH v2] PCI: Introduce flag for detached virtual functions

no longer able to work with vfio-pci as the firmware does not provide emulation of the PCI_COMMAND_MEMORY bit. In this case, let's explicitly recognize these detached VFs so that vfio-pci can allow memory access to them again. Signed-off-by: Matthew Rosato --- arch/s390/pci/pci.c

Re: [PATCH] PCI: Introduce flag for detached virtual functions

On 8/12/20 12:43 PM, Alex Williamson wrote: On Wed, 12 Aug 2020 10:50:17 -0400 Matthew Rosato wrote: s390x has the notion of providing VFs to the kernel in a manner where the associated PF is inaccessible other than via firmware. These are not treated as typical VFs and access to them

[PATCH] PCI: Identifying detached virtual functions

e detached VFs and subsequently provide this information to vfio-pci so that it knows to also accept the lack of PCI_COMMAND_MEMORY for these sorts of devices. For now the bit is only set for s390x but other architectures could opt in to it as well if needed. Matthew Rosato (1): PCI: Introduce fla

[PATCH] PCI: Introduce flag for detached virtual functions

no longer able to work with vfio-pci as the firmware does not provide emulation of the PCI_COMMAND_MEMORY bit. In this case, let's explicitly recognize these detached VFs so that vfio-pci can allow memory access to them again. Signed-off-by: Matthew Rosato Reviewed-by: Pierre Morel Reviewed

Re: [PATCH v4 4/4] vfio: pci: Using a device region to retrieve zPCI information

On 9/19/19 6:57 PM, Alex Williamson wrote: > On Fri, 6 Sep 2019 20:13:51 -0400 > Matthew Rosato wrote: > >> From: Pierre Morel >> >> We define a new configuration entry for VFIO/PCI, VFIO_PCI_ZDEV >> >> When the VFIO_PCI_ZDEV feature is configur

Re: [PATCH net,stable v4 0/3] vhost: fix a few skb leaks

On 12/01/2017 09:47 AM, Michael S. Tsirkin wrote: > On Fri, Dec 01, 2017 at 05:10:35AM -0500, w...@redhat.com wrote: >> From: Wei Xu >> >> Matthew found a roughly 40% tcp throughput regression with commit >> c67df11f(vhost_net: try batch dequing from skb array) as discussed >> in

Re: [PATCH net,stable v4 0/3] vhost: fix a few skb leaks

On 12/01/2017 09:47 AM, Michael S. Tsirkin wrote: > On Fri, Dec 01, 2017 at 05:10:35AM -0500, w...@redhat.com wrote: >> From: Wei Xu >> >> Matthew found a roughly 40% tcp throughput regression with commit >> c67df11f(vhost_net: try batch dequing from skb array) as discussed >> in the following