From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>
Subject: [PATCH 4.14 06/12] vfio/pci: Fix SR-IOV VF handling with MMIO blocking
Date: Fri, 11 Sep 2020 14:47:00 +0200 [thread overview]
Message-ID: <20200911122458.729118580@linuxfoundation.org> (raw)
In-Reply-To: <20200911122458.413137406@linuxfoundation.org>
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)
next prev parent reply other threads:[~2020-09-11 16:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 12:46 [PATCH 4.14 00/12] 4.14.198-rc1 review Greg Kroah-Hartman
2020-09-11 12:46 ` [PATCH 4.14 01/12] ALSA; firewire-tascam: exclude Tascam FE-8 from detection Greg Kroah-Hartman
2020-09-11 12:46 ` [PATCH 4.14 02/12] block: ensure bdi->io_pages is always initialized Greg Kroah-Hartman
2020-09-11 12:46 ` [PATCH 4.14 03/12] vfio/type1: Support faulting PFNMAP vmas Greg Kroah-Hartman
2020-09-11 12:46 ` [PATCH 4.14 04/12] vfio-pci: Fault mmaps to enable vma tracking Greg Kroah-Hartman
2020-09-11 12:46 ` [PATCH 4.14 05/12] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory Greg Kroah-Hartman
2020-09-11 12:47 ` Greg Kroah-Hartman [this message]
2020-09-11 12:47 ` [PATCH 4.14 07/12] bnxt: dont enable NAPI until rings are ready Greg Kroah-Hartman
2020-09-11 12:47 ` [PATCH 4.14 08/12] netlabel: fix problems with mapping removal Greg Kroah-Hartman
2020-09-11 12:47 ` [PATCH 4.14 09/12] net: usb: dm9601: Add USB ID of Keenetic Plus DSL Greg Kroah-Hartman
2020-09-11 12:47 ` [PATCH 4.14 10/12] sctp: not disable bh in the whole sctp_get_port_local() Greg Kroah-Hartman
2020-09-11 12:47 ` [PATCH 4.14 11/12] tipc: fix shutdown() of connectionless socket Greg Kroah-Hartman
2020-09-11 12:47 ` [PATCH 4.14 12/12] net: disable netpoll on fresh napis Greg Kroah-Hartman
2020-09-11 17:10 ` [PATCH 4.14 00/12] 4.14.198-rc1 review Jon Hunter
2020-09-11 22:30 ` Shuah Khan
2020-09-12 2:18 ` Guenter Roeck
2020-09-12 7:52 ` Naresh Kamboju
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200911122458.729118580@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=alex.williamson@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).