5.4-stable patches

added patches:
	vfio-pci-fix-sr-iov-vf-handling-with-mmio-blocking.patch

diff --git a/queue-5.4/series b/queue-5.4/series
index daca5416cfadab0edc2600e3914bf5b317429126..e260aa1fcd13bf3c8edffad26a4119b0303994c6 100644 (file)
--- a/queue-5.4/series
+++ b/queue-5.4/series
@@ -119,3 +119,4 @@ dm-thin-metadata-avoid-returning-cmd-bm-wild-pointer-on-error.patch
 dm-thin-metadata-fix-use-after-free-in-dm_bm_set_read_only.patch
 mm-slub-fix-conversion-of-freelist_corrupted.patch
 mm-madvise-fix-vma-user-after-free.patch
+vfio-pci-fix-sr-iov-vf-handling-with-mmio-blocking.patch

diff --git a/queue-5.4/vfio-pci-fix-sr-iov-vf-handling-with-mmio-blocking.patch b/queue-5.4/vfio-pci-fix-sr-iov-vf-handling-with-mmio-blocking.patch
new file mode 100644 (file)
index 0000000..e275b69
--- /dev/null
+++ b/queue-5.4/vfio-pci-fix-sr-iov-vf-handling-with-mmio-blocking.patch
@@ -0,0 +1,62 @@
+From ebfa440ce38b7e2e04c3124aa89c8a9f4094cf21 Mon Sep 17 00:00:00 2001
+From: Alex Williamson <alex.williamson@redhat.com>
+Date: Thu, 25 Jun 2020 11:04:23 -0600
+Subject: vfio/pci: Fix SR-IOV VF handling with MMIO blocking
+
+From: Alex Williamson <alex.williamson@redhat.com>
+
+commit ebfa440ce38b7e2e04c3124aa89c8a9f4094cf21 upstream.
+
+SR-IOV VFs do not implement the memory enable bit of the command
+register, therefore this bit is not set in config space after
+pci_enable_device().  This leads to an unintended difference
+between PF and VF in hand-off state to the user.  We can correct
+this by setting the initial value of the memory enable bit in our
+virtualized config space.  There's really no need however to
+ever fault a user on a VF though as this would only indicate an
+error in the user's management of the enable bit, versus a PF
+where the same access could trigger hardware faults.
+
+Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory")
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/vfio/pci/vfio_pci_config.c |   17 ++++++++++++++++-
+ 1 file changed, 16 insertions(+), 1 deletion(-)
+
+--- a/drivers/vfio/pci/vfio_pci_config.c
++++ b/drivers/vfio/pci/vfio_pci_config.c
+@@ -398,9 +398,15 @@ static inline void p_setd(struct perm_bi
+ /* Caller should hold memory_lock semaphore */
+ bool __vfio_pci_memory_enabled(struct vfio_pci_device *vdev)
+ {
++      struct pci_dev *pdev = vdev->pdev;
+       u16 cmd = le16_to_cpu(*(__le16 *)&vdev->vconfig[PCI_COMMAND]);
+ 
+-      return cmd & PCI_COMMAND_MEMORY;
++      /*
++       * SR-IOV VF memory enable is handled by the MSE bit in the
++       * PF SR-IOV capability, there's therefore no need to trigger
++       * faults based on the virtual value.
++       */
++      return pdev->is_virtfn || (cmd & PCI_COMMAND_MEMORY);
+ }
+ 
+ /*
+@@ -1726,6 +1732,15 @@ int vfio_config_init(struct vfio_pci_dev
+                                vconfig[PCI_INTERRUPT_PIN]);
+ 
+               vconfig[PCI_INTERRUPT_PIN] = 0; /* Gratuitous for good VFs */
++
++              /*
++               * VFs do no implement the memory enable bit of the COMMAND
++               * register therefore we'll not have it set in our initial
++               * copy of config space after pci_enable_device().  For
++               * consistency with PFs, set the virtual enable bit here.
++               */
++              *(__le16 *)&vconfig[PCI_COMMAND] |=
++                                      cpu_to_le16(PCI_COMMAND_MEMORY);
+       }
+ 
+       if (!IS_ENABLED(CONFIG_VFIO_PCI_INTX) || vdev->nointx)