This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough
From: Weidong Han <weidong.han@xxxxxxxxx>
Date: Fri, 05 Feb 2010 09:52:47 +0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 04 Feb 2010 17:53:28 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19306.65275.325707.253978@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <60E426D47DE8EA47AA104E65008A100D1621AFC6F5@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <19306.65275.325707.253978@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (Windows/20090302)
Ian Jackson wrote:
Han, Weidong writes ("[Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough 
Some registers of Intel IGD are mapped in host bridge, so it needs
to passthrough these registers of physical host bridge to guest
because emulated host bridge in guest doesn't have these mappings.

Some VBIOSs and drivers ssume the IGD BDF (bus:device:function) is
always 00:02.0, so this patch reserves 00:02.0 for assigned IGD in

Thanks for the contribution, which I have applied with a very small
change to avoid having an open else at #endif.

However the part in pci.c is really very ugly indeed.  If we ever get
around to rebasing to recent upstream qemu and trying to upstream our
patches, this is sure to be dropped.  So you might profitably spend
some time thinking how to make it less ugly.


Thanks for check-in. I agree the hacking in pci.c is not elegant. We will think how to make it cleaner.


+    /* host bridge reads for IGD passthrough */
+    if ( igd_passthru && pci_dev->devfn == 0x00 )
+    {
+        val = pci_dev->config_read(pci_dev, config_addr, len);
+        if ( config_addr == 0x00 && len == 4 )
+            val = pt_pci_host_read_long(0, 0, 0, 0x00);
+        else if ( config_addr == 0x02 ) // Device ID
+            val = pt_pci_host_read_word(0, 0, 0, 0x02);
+        else if ( config_addr == 0x52 ) // GMCH Graphics Control Register
+            val = pt_pci_host_read_word(0, 0, 0, 0x52);
+        else if ( config_addr == 0xa0 ) // GMCH Top of Memory Register
+            val = pt_pci_host_read_word(0, 0, 0, 0xa0);
+    }
+    else if ( igd_passthru && pci_dev->devfn == 0x10 &&
+              config_addr == 0xfc ) // read on IGD device
+        val = 0;  // use SMI to communicate with the system BIOS
+    else
+        val = pci_dev->config_read(pci_dev, config_addr, len);

Xen-devel mailing list