From: Alex Williamson <alex.williamson@redhat.com>
To: qemu-devel@nongnu.org
Cc: alex.williamson@redhat.com
Subject: [Qemu-devel] [PULL 1/2] vfio/pci: Fix RTL8168 NIC quirks
Date: Thu, 23 Jul 2015 13:06:35 -0600 [thread overview]
Message-ID: <20150723190627.28669.75319.stgit@gimli.home> (raw)
In-Reply-To: <20150723190414.28669.75130.stgit@gimli.home>
The RTL8168 quirk correctly describes using bit 31 as a signal to
mark a latch/completion, but the code mistakenly uses bit 28. This
causes the Realtek driver to spin on this register for quite a while,
20k cycles on Windows 7 v7.092 driver. Then it gets frustrated and
tries to set the bit itself and spins for another 20k cycles. For
some this still results in a working driver, for others not. About
the only thing the code really does in its current form is protect
the guest from sneaking in writes to the real hardware MSI-X table.
The fix is obviously to use bit 31 as we document that we should.
The other problem doesn't seem to affect current drivers as nobody
seems to use these window registers for writes to the MSI-X table, but
we need to use the stored data when a write is triggered, not the
value of the current write, which only provides the offset.
Note that only the Windows drivers from Realtek seem to use these
registers, the Microsoft drivers provided with Windows 8.1 do not
access them, nor do Linux in-kernel drivers.
Link: https://bugs.launchpad.net/qemu/+bug/1384892
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-stable@nongnu.org # v2.1+
---
hw/vfio/pci.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 2ed877f..0af762a 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1517,7 +1517,7 @@ static uint64_t vfio_rtl8168_window_quirk_read(void *opaque,
memory_region_name(&quirk->mem),
vdev->vbasedev.name);
- return quirk->data.address_match ^ 0x10000000U;
+ return quirk->data.address_match ^ 0x80000000U;
}
break;
case 0: /* data */
@@ -1558,7 +1558,7 @@ static void vfio_rtl8168_window_quirk_write(void *opaque, hwaddr addr,
switch (addr) {
case 4: /* address */
if ((data & 0x7fff0000) == 0x10000) {
- if (data & 0x10000000U &&
+ if (data & 0x80000000U &&
vdev->pdev.cap_present & QEMU_PCI_CAP_MSIX) {
trace_vfio_rtl8168_window_quirk_write_table(
@@ -1566,11 +1566,9 @@ static void vfio_rtl8168_window_quirk_write(void *opaque, hwaddr addr,
vdev->vbasedev.name);
memory_region_dispatch_write(&vdev->pdev.msix_table_mmio,
- (hwaddr)(quirk->data.address_match
- & 0xfff),
- data,
- size,
- MEMTXATTRS_UNSPECIFIED);
+ (hwaddr)(data & 0xfff),
+ (uint64_t)quirk->data.address_mask,
+ size, MEMTXATTRS_UNSPECIFIED);
}
quirk->data.flags = 1;
next prev parent reply other threads:[~2015-07-23 19:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 19:06 [Qemu-devel] [PULL 0/2] vfio-pci fixes for v2.4 Alex Williamson
2015-07-23 19:06 ` Alex Williamson [this message]
2015-07-23 19:06 ` [Qemu-devel] [PULL 2/2] vfio/pci: Fix bootindex Alex Williamson
2015-07-24 10:11 ` [Qemu-devel] [PULL 0/2] vfio-pci fixes for v2.4 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=20150723190627.28669.75319.stgit@gimli.home \
--to=alex.williamson@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).