From: Greg Kroah-Hartman Date: Tue, 8 Sep 2020 14:33:30 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v4.14.197~11 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6c8e03acbe072596f79a7b86e44a10f427abb218;p=thirdparty%2Fkernel%2Fstable-queue.git 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 987eb48691a..7a7586ed458 100644 --- 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 index 00000000000..b66cdbd8b09 --- /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 +Date: Thu, 25 Jun 2020 11:04:23 -0600 +Subject: vfio/pci: Fix SR-IOV VF handling with MMIO blocking + +From: Alex Williamson + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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)