4.19-stable patches

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

diff --git a/queue-4.19/series b/queue-4.19/series
index 987eb48691a8fa1252db6c925a707f7cc3e2df79..7a7586ed4589f898653a4759761bb976bffc46b1 100644 (file)
--- a/queue-4.19/series
+++ b/queue-4.19/series
@@ -81,3 +81,4 @@ kvm-arm64-add-kvm_extable-for-vaxorcism-code.patch
 kvm-arm64-defer-guest-entry-when-an-asynchronous-exception-is-pending.patch
 kvm-arm64-survive-synchronous-exceptions-caused-by-at-instructions.patch
 kvm-arm64-set-hcr_el2.ptw-to-prevent-at-taking-synchronous-exception.patch
+vfio-pci-fix-sr-iov-vf-handling-with-mmio-blocking.patch

diff --git a/queue-4.19/vfio-pci-fix-sr-iov-vf-handling-with-mmio-blocking.patch b/queue-4.19/vfio-pci-fix-sr-iov-vf-handling-with-mmio-blocking.patch
new file mode 100644 (file)
index 0000000..b66cdbd
--- /dev/null
+++ b/queue-4.19/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
+@@ -401,9 +401,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);
+ }
+ 
+ /*
+@@ -1732,6 +1738,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)