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

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

[Han, Weidong]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

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 guest.

Signed-off-by: Weidong Han <weidong.han@intel.com>

[-- Attachment #2: qemu-igd.patch --]
[-- Type: application/octet-stream, Size: 5624 bytes --]

From 1adbc6160851e72f3c080717a85938976619b617 Mon Sep 17 00:00:00 2001
From: Weidong Han <weidong.han@intel.com>
Date: Thu, 4 Feb 2010 09:46:24 +0800
Subject: [PATCH] Intel IGD passthrough support

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
guest.

Signed-off-by: Weidong Han <weidong.han@intel.com>
---
 hw/pass-through.c |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 hw/pass-through.h |    4 +++
 hw/pci.c          |   32 +++++++++++++++++++++++++++++-
 3 files changed, 90 insertions(+), 2 deletions(-)

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 9371a39..ecb3d6f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -94,6 +94,7 @@
 #include <sys/ioctl.h>
 
 extern int gfx_passthru;
+int igd_passthru = 0;
 
 struct php_dev {
     struct pt_dev *pt_dev;
@@ -915,6 +916,8 @@ static int find_free_vslot(void)
 
     for ( slot = 0; slot < NR_PCI_DEV; slot++ )
     {
+        if ( gfx_passthru && slot == 0x2 )
+            continue;
         for ( func = 0; func < NR_PCI_FUNC; func++ )
         {
             devfn = PCI_DEVFN(slot, func);
@@ -944,7 +947,16 @@ static int __insert_to_pci_devfn(int bus, int dev, int func, int devfn,
     PCIBus *e_bus = dpci_infos.e_bus;
     int vslot;
 
-    if ( devfn & AUTO_PHP_SLOT )
+    if ( gfx_passthru && bus == 0x0 && dev == 0x2 )
+    {
+        igd_passthru = 1;
+
+        /* make virtual BDF of Intel IGD in guest is same with host */
+        devfn = PCI_DEVFN(dev, func);
+        if ( test_pci_devfn(devfn) || pci_devfn_in_use(e_bus, devfn) )
+            return -2;
+    }
+    else if ( devfn & AUTO_PHP_SLOT )
     {
         vslot = find_free_vslot();
         if (vslot < 0)
@@ -2073,6 +2085,48 @@ static uint32_t find_ext_cap_offset(struct pci_dev *pci_dev, uint32_t cap)
     return 0;
 }
 
+u8 pt_pci_host_read_byte(int bus, int dev, int fn, u32 addr)
+{
+    struct pci_dev *pci_dev;
+    u8 val;
+
+    pci_dev = pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
+    if ( !pci_dev )
+        return 0;
+
+    val = pci_read_byte(pci_dev, addr);
+    pci_free_dev(pci_dev);
+    return val;
+}
+
+u16 pt_pci_host_read_word(int bus, int dev, int fn, u32 addr)
+{
+    struct pci_dev *pci_dev;
+    u16 val;
+
+    pci_dev = pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
+    if ( !pci_dev )
+        return 0;
+
+    val = pci_read_word(pci_dev, addr);
+    pci_free_dev(pci_dev);
+    return val;
+}
+
+u32 pt_pci_host_read_long(int bus, int dev, int fn, u32 addr)
+{
+    struct pci_dev *pci_dev;
+    u32 val;
+
+    pci_dev = pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
+    if ( !pci_dev )
+        return 0;
+
+    val = pci_read_long(pci_dev, addr);
+    pci_free_dev(pci_dev);
+    return val;
+}
+
 /* parse BAR */
 static int pt_bar_reg_parse(
         struct pt_dev *ptdev, struct pt_reg_info_tbl *reg)
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 3156897..f8a0c73 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -407,5 +407,9 @@ static inline pciaddr_t pt_pci_base_addr(pciaddr_t base)
 
 uint8_t pci_intx(struct pt_dev *ptdev);
 
+u8 pt_pci_host_read_byte(int bus, int dev, int fn, u32 addr);
+u16 pt_pci_host_read_word(int bus, int dev, int fn, u32 addr);
+u32 pt_pci_host_read_long(int bus, int dev, int fn, u32 addr);
+
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pci.c b/hw/pci.c
index d7c516e..7f6bfa5 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -31,6 +31,8 @@
 #include "exec-all.h"
 #include "qemu-xen.h"
 
+extern int igd_passthru;
+
 //#define DEBUG_PCI
 
 struct PCIBus {
@@ -230,6 +232,12 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name,
 
     if (devfn < 0) {
         for(devfn = bus->devfn_min ; devfn < 256; devfn += 8) {
+#ifdef CONFIG_PASSTHROUGH
+            /* reserve 00:02.0, because some BIOSs and drivers assume
+             * 00:02.0 for Intel IGD */
+            if ( gfx_passthru && devfn == 0x10 )
+                continue;
+#endif
             if ( !pci_devfn_in_use(bus, devfn) )
                 goto found;
         }
@@ -611,7 +619,29 @@ uint32_t pci_data_read(void *opaque, uint32_t addr, int len)
         goto the_end;
     }
     config_addr = addr & 0xff;
-    val = pci_dev->config_read(pci_dev, config_addr, len);
+
+#ifdef CONFIG_PASSTHROUGH
+    /* 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
+#endif
+        val = pci_dev->config_read(pci_dev, config_addr, len);
+
 #if defined(DEBUG_PCI)
     printf("pci_config_read: %s: addr=%02x val=%08x len=%d\n",
            pci_dev->name, config_addr, val, len);
-- 
1.6.0.4


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

[Ian Jackson]

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
> guest.

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,
Ian.

> +#ifdef CONFIG_PASSTHROUGH
> +    /* 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
> +#endif
> +        val = pci_dev->config_read(pci_dev, config_addr, len);
> +

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

[Weidong Han]

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
>> guest.
>>     
>
> 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,
> Ian.
>   

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

Regards,
Weidong


>   
>> +#ifdef CONFIG_PASSTHROUGH
>> +    /* 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
>> +#endif
>> +        val = pci_dev->config_read(pci_dev, config_addr, len);
>> +
>>     

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

[Isaku Yamahata]

On Fri, Feb 05, 2010 at 09:52:47AM +0800, Weidong Han wrote:
> 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
>>> guest.
>>>     
>>
>> 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,
>> Ian.
>>   
>
> Thanks for check-in.  I agree the hacking in pci.c is not elegant. We  
> will think how to make it cleaner.

This can be moved out as read_config callback.
See 400fx_init() calling pci_register_device() in pciix_pci.c
and some wrapper of pt_cpi_read_config().

thanks,

>
> Regards,
> Weidong
>
>
>>   
>>> +#ifdef CONFIG_PASSTHROUGH
>>> +    /* 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
>>> +#endif
>>> +        val = pci_dev->config_read(pci_dev, config_addr, len);
>>> +
>>>     
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

-- 
yamahata

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

[Weidong Han]

Isaku Yamahata wrote:
> On Fri, Feb 05, 2010 at 09:52:47AM +0800, Weidong Han wrote:
>   
>> 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
>>>> guest.
>>>>     
>>>>         
>>> 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,
>>> Ian.
>>>   
>>>       
>> Thanks for check-in.  I agree the hacking in pci.c is not elegant. We  
>> will think how to make it cleaner.
>>     
>
> This can be moved out as read_config callback.
> See 400fx_init() calling pci_register_device() in pciix_pci.c
> and some wrapper of pt_cpi_read_config().
>
> thanks,
>
>   
Sound reasonable.

Regards,
Weidong
>> Regards,
>> Weidong
>>
>>
>>     
>>>   
>>>       
>>>> +#ifdef CONFIG_PASSTHROUGH
>>>> +    /* 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
>>>> +#endif
>>>> +        val = pci_dev->config_read(pci_dev, config_addr, len);
>>>> +
>>>>     
>>>>         
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>     
>
>   

Re: VT-d support proprietary NVidia/ATI GPU passthrough

[Weidong Han]

Timothy J. Moore wrote:
> Dear Xen-developers,
>
> Now that we have IGD passthough patches in the xen source tree, would it be possible to start working on support for other vendor cards?
>   
Xen already implemented basic gfx passthrough a few months ago, and 
supported "virtualization friendly" gfx passthrough, such as nVidia 
FX3800. But for most discrete GPU, they need various hacks, such as 
vBAR=pBAR.
> I know and have working the necessary patches to enable PCI/VGA Pass-through for non IGD, but it's a long way from stable - 
>
> Is there a way that vendor specific resets or FLR code could be implemented that will provide a stable experience when using VGA passthrough with NVidia and plugging/unplugging and starting/rebooting DomUs?
>   
yes, FLR is a problem for gfx cards which don't support standard FLR 
capability. FLR is required for passthrough, but lots of existing gfx 
cards don't have this capability, and only gfx vendors know how to 
implement vendor specific reset.
> Can the vBAR-pBAR code that Wiedong provided be implemented in a more dynamic way? (currently requires static mem ranges)
>   
Yes, the patch is experimental, and not suitable for upstream now.

Regards,
Weidong
> Thanks all, anyone who could help please shout !
>
> Tim
>   

RE: VT-d support proprietary NVidia/ATI GPU passthrough

[Timothy J. Moore]

How can xen implement these vendor specific resets?  How could we find out the gfx vendor specific stuff?

Can we take anything from the opensource NV, nouveau, or Gallium3D drivers?


-----Original Message-----
From: Weidong Han [mailto:weidong.han@intel.com] 
Sent: 22 February 2010 07:08
To: Timothy J. Moore
Cc: xen-devel@lists.xensource.com
Subject: Re: VT-d support proprietary NVidia/ATI GPU passthrough

Timothy J. Moore wrote:
> Dear Xen-developers,
>
> Now that we have IGD passthough patches in the xen source tree, would it be possible to start working on support for other vendor cards?
>
  
Xen already implemented basic gfx passthrough a few months ago, and 
supported "virtualization friendly" gfx passthrough, such as nVidia 
FX3800. But for most discrete GPU, they need various hacks, such as 
vBAR=pBAR.

> I know and have working the necessary patches to enable PCI/VGA Pass-through for non IGD, but it's a long way from stable - 
>
> Is there a way that vendor specific resets or FLR code could be implemented that will provide a stable experience when using VGA passthrough with NVidia and plugging/unplugging and starting/rebooting DomUs?
>   

yes, FLR is a problem for gfx cards which don't support standard FLR 
capability. FLR is required for passthrough, but lots of existing gfx 
cards don't have this capability, and only gfx vendors know how to 
implement vendor specific reset.


> Can the vBAR-pBAR code that Wiedong provided be implemented in a more dynamic way? (currently requires static mem ranges)
>   


Yes, the patch is experimental, and not suitable for upstream now.

Regards,
Weidong
> Thanks all, anyone who could help please shout !
>
> Tim
>   

Re: RE: VT-d support proprietary NVidia/ATI GPU passthrough

[Konrad Rzeszutek Wilk]

On Mon, Feb 22, 2010 at 12:32:48PM +0000, Timothy J. Moore wrote:
> How can xen implement these vendor specific resets?  How could we find out the gfx vendor specific stuff?
> 
> Can we take anything from the opensource NV, nouveau, or Gallium3D drivers?

As I understand it, the reason for the FLR is to re-initialize the video
cards to re-run through the basic ROM code. Pretty much exactly the same
thing that is done during machine startup. But for gfx pass-through you
need to this with the Bochs code running so it can call the gfx BIOS.

I don't think that the open-source drivers go so low to re-initialize
the card?

Thought perhaps another way to do this, is to put the cards in D3 (cold)
state and then re-initialize them back up? (this is btw, what the
pciback drivers does when it seizes the card).

Re: RE: VT-d support proprietary NVidia/ATI GPU passthrough

[Weidong Han]

Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 22, 2010 at 12:32:48PM +0000, Timothy J. Moore wrote:
>   
>> How can xen implement these vendor specific resets?  How could we find out the gfx vendor specific stuff?
>>
>> Can we take anything from the opensource NV, nouveau, or Gallium3D drivers?
>>     
>
> As I understand it, the reason for the FLR is to re-initialize the video
> cards to re-run through the basic ROM code. Pretty much exactly the same
> thing that is done during machine startup. But for gfx pass-through you
> need to this with the Bochs code running so it can call the gfx BIOS.
>
> I don't think that the open-source drivers go so low to re-initialize
> the card?
>
> Thought perhaps another way to do this, is to put the cards in D3 (cold)
> state and then re-initialize them back up? (this is btw, what the
> pciback drivers does when it seizes the card).
>   
reset through Dstate transition is not guarantee to work for all 
devices. As we observed, it seems didn't work for Intel IGD, so we 
implemented vendor specific reset for Intel IGD.

Regards,
Weidong

RE: RE: VT-d support proprietary NVidia/ATI GPU passthrough

[Timothy J. Moore]

I agree, pciback Dstate transition does not seem to work with Nvidia cards either ..

Also, I believe XCI attempts Dstate + secondary bus reset + FLR and they don't work too!

Seems to be vendor specific calls that are needed, but where can we obtain this info ?

-----Original Message-----
From: Weidong Han [mailto:weidong.han@intel.com] 
Sent: 23 February 2010 01:16
To: Konrad Rzeszutek Wilk
Cc: Timothy J. Moore; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] RE: VT-d support proprietary NVidia/ATI GPU passthrough

Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 22, 2010 at 12:32:48PM +0000, Timothy J. Moore wrote:
>   
>> How can xen implement these vendor specific resets?  How could we find out the gfx vendor specific stuff?
>>
>> Can we take anything from the opensource NV, nouveau, or Gallium3D drivers?
>>     
>
> As I understand it, the reason for the FLR is to re-initialize the video
> cards to re-run through the basic ROM code. Pretty much exactly the same
> thing that is done during machine startup. But for gfx pass-through you
> need to this with the Bochs code running so it can call the gfx BIOS.
>
> I don't think that the open-source drivers go so low to re-initialize
> the card?
>
> Thought perhaps another way to do this, is to put the cards in D3 (cold)
> state and then re-initialize them back up? (this is btw, what the
> pciback drivers does when it seizes the card).
>   
reset through Dstate transition is not guarantee to work for all 
devices. As we observed, it seems didn't work for Intel IGD, so we 
implemented vendor specific reset for Intel IGD.

Regards,
Weidong