From: Alex Williamson <alex.williamson@hp.com>
To: kvm <kvm@vger.kernel.org>
Cc: Sheng Yang <sheng@linux.intel.com>
Subject: [RFC PATCH] PCI pass-through fixups
Date: Fri, 03 Apr 2009 14:16:56 -0600 [thread overview]
Message-ID: <1238789816.15558.399.camel@lappy> (raw)
I'm wondering if we need a spot for device specific fixups for PCI
pass-through. In the example below, I want to expose a single port of
an Intel 82571EB quad port copper NIC to a guest. It works great until
I shutdown the guest, at which point the guest e1000e driver knows by
the device ID that the NIC is a quad port, and blindly attempts to
twiddle some bits on the bridge above it (that doesn't exist).
Obviously some robustness could be added to the driver, but would it
make sense to do something like below and automatically remap these
devices to identical single port device IDs? Thanks,
Alex
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
--
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index b7f9fa6..1c6d1e8 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -427,6 +427,35 @@ static int assigned_dev_register_regions(PCIRegion *io_regions,
return 0;
}
+static void assigned_device_fixup(AssignedDevice *pci_dev)
+{
+ uint16_t vendor_id, device_id;
+
+ vendor_id = pci_dev->dev.config[0] | pci_dev->dev.config[1] << 8;
+ device_id = pci_dev->dev.config[2] | pci_dev->dev.config[3] << 8;
+
+ switch (vendor_id) {
+ case 0x8086:
+ switch (device_id) {
+ case 0x10A4:
+ case 0x10BC:
+ /* quad port copper -> single port copper */
+ pci_dev->dev.config[2] = 0x5E;
+ break;
+ case 0x10A5:
+ /* quad port fiber -> single port fiber */
+ pci_dev->dev.config[2] = 0x5F;
+ break;
+ case 0x10DA:
+ case 0x10D9:
+ /* dual/quad port serdes -> single port serdes */
+ pci_dev->dev.config[2] = 0x60;
+ break;
+ }
+ break;
+ }
+}
+
static int get_real_device(AssignedDevice *pci_dev, uint8_t r_bus,
uint8_t r_dev, uint8_t r_func)
{
@@ -524,6 +553,8 @@ again:
}
fclose(f);
+ assigned_device_fixup(pci_dev);
+
/* dealing with virtual function device */
snprintf(name, sizeof(name), "%sphysfn/", dir);
if (!stat(name, &statbuf))
next reply other threads:[~2009-04-03 20:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-03 20:16 Alex Williamson [this message]
2009-04-07 0:02 ` [RFC PATCH] PCI pass-through fixups Chris Wright
2009-04-07 6:25 ` Sheng Yang
2009-04-07 14:54 ` Chris Wright
2009-04-07 15:23 ` Alex Williamson
2009-04-07 15:47 ` Chris Wright
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=1238789816.15558.399.camel@lappy \
--to=alex.williamson@hp.com \
--cc=kvm@vger.kernel.org \
--cc=sheng@linux.intel.com \
/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