From patchwork Fri Apr 3 20:16:56 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 16226 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n33KHqCC005130 for ; Fri, 3 Apr 2009 20:17:52 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756608AbZDCURQ (ORCPT ); Fri, 3 Apr 2009 16:17:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760611AbZDCURQ (ORCPT ); Fri, 3 Apr 2009 16:17:16 -0400 Received: from g4t0014.houston.hp.com ([15.201.24.17]:30889 "EHLO g4t0014.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755098AbZDCURP (ORCPT ); Fri, 3 Apr 2009 16:17:15 -0400 Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g4t0014.houston.hp.com (Postfix) with ESMTP id 3573E2449E; Fri, 3 Apr 2009 20:17:14 +0000 (UTC) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.11.146.30]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 169A234030; Fri, 3 Apr 2009 20:17:14 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl.fc.hp.com (Postfix) with ESMTP id CAC1239C00E; Fri, 3 Apr 2009 14:17:13 -0600 (MDT) X-Virus-Scanned: Debian amavisd-new at ldl.fc.hp.com Received: from ldl.fc.hp.com ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHMcuyhYoPgN; Fri, 3 Apr 2009 14:17:12 -0600 (MDT) Received: from [10.91.73.10] (lart.fc.hp.com [15.11.146.31]) by ldl.fc.hp.com (Postfix) with ESMTP id 71F7039C00B; Fri, 3 Apr 2009 14:17:12 -0600 (MDT) Subject: [RFC PATCH] PCI pass-through fixups From: Alex Williamson To: kvm Cc: Sheng Yang Organization: OSLO R&D Date: Fri, 03 Apr 2009 14:16:56 -0600 Message-Id: <1238789816.15558.399.camel@lappy> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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 --- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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))