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 CONFIG_VFIO_P
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
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 and
_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(+)
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
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
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 these to
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
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
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
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
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
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
r ISM 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_z
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: Pass
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
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(-)
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
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 device
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
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 for
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 will
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
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
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
r ISM 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_z
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
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
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(-)
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
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
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
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
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
egion.
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 vfi
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
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.
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 a
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
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 is
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/s39
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
.
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
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
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
_ZDEV 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:
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
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/in
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
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
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
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 for
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 is
.
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
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 del
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
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
_ZDEV 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
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
DMA 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
tchset to 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/vfi
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 use
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
tchset to 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 abov
DMA 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
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 use
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
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/drivers/vfio/vfio_iommu_type1.c
mation 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 ch
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 +
in
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
oposal.
[1]: https://marc.info/?l=linux-pci&m=159856041930022&w=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/
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
R
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 to
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
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
to look at the dev_flags bit instead of is_virtfn
[1]: https://marc.info/?l=linux-pci&m=159856041930022&w=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/
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 a
e/ 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 via firmw
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
and 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
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
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 Matt
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 is
de 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 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/
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 is
se 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: Introduc
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
Review
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
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 thr
91 matches
Mail list logo
