From: Alex Williamson <alex.williamson@redhat.com>
To: aliguori@amazon.com
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: [Qemu-devel] [PULL v2 4/8] vfio: Filter out bogus mappings
Date: Tue, 28 Jan 2014 08:45:27 -0700 [thread overview]
Message-ID: <20140128154526.30053.34183.stgit@bling.home> (raw)
In-Reply-To: <20140128153451.30053.92976.stgit@bling.home>
Since 57271d63 we now see spurious mappings with the upper bits set
if 64bit PCI BARs are sized while enabled. The guest writes a mask
of 0xffffffff to the lower BAR to size it, then restores it, then
writes the same mask to the upper BAR resulting in a spurious BAR
mapping into the last 4G of the 64bit address space. Most
architectures do not support or make use of the full 64bits address
space for PCI BARs, so we filter out mappings with the high bit set.
Long term, we probably need to think about vfio telling us the
address width limitations of the IOMMU.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
---
hw/misc/vfio.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index 30b1a78..d304213 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -2156,7 +2156,14 @@ static int vfio_dma_map(VFIOContainer *container, hwaddr iova,
static bool vfio_listener_skipped_section(MemoryRegionSection *section)
{
- return !memory_region_is_ram(section->mr);
+ return !memory_region_is_ram(section->mr) ||
+ /*
+ * Sizing an enabled 64-bit BAR can cause spurious mappings to
+ * addresses in the upper part of the 64-bit address space. These
+ * are never accessed by the CPU and beyond the address width of
+ * some IOMMU hardware. TODO: VFIO should tell us the IOMMU width.
+ */
+ section->offset_within_address_space & (1ULL << 63);
}
static void vfio_listener_region_add(MemoryListener *listener,
next prev parent reply other threads:[~2014-01-28 15:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-28 15:44 [Qemu-devel] [PULL v2 0/8] vfio pull request Alex Williamson
2014-01-28 15:45 ` [Qemu-devel] [PULL v2 1/8] vfio: Destroy memory regions Alex Williamson
2014-01-28 15:45 ` [Qemu-devel] [PULL v2 2/8] vfio: warn if host device rom can't be read Alex Williamson
2014-01-28 15:45 ` [Qemu-devel] [PULL v2 3/8] vfio: Do not reattempt a failed rom read Alex Williamson
2014-01-28 15:45 ` Alex Williamson [this message]
2014-01-28 15:58 ` [Qemu-devel] [PULL v2 0/8] vfio pull request Alex Williamson
2014-02-01 22:15 ` Peter Maydell
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=20140128154526.30053.34183.stgit@bling.home \
--to=alex.williamson@redhat.com \
--cc=aliguori@amazon.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.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).