[PATCH] VT-d: improve RMRR validity checking

[PATCH] VT-d: improve RMRR validity checking

[Han, Weidong]

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

Currently, Xen checks RMRR range and disables VT-d if RMRR range is set incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the device under its scope are not pci discoverable, because the RMRR won't be used by non-existed or disabled devices. 

This patch ignores the RMRR if the device under its scope are not pci discoverable, and only checks the validity of RMRRs that are actually used. In order to avoid duplicate pci device detection code, this patch defines a function pci_device_detect for it.

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

[-- Attachment #2: rmrr.patch --]
[-- Type: application/octet-stream, Size: 4672 bytes --]

diff -r 104110651ff6 xen/drivers/passthrough/pci.c
--- a/xen/drivers/passthrough/pci.c	Wed Jan 20 22:50:09 2010 +0800
+++ b/xen/drivers/passthrough/pci.c	Thu Jan 21 10:17:52 2010 +0800
@@ -362,6 +362,21 @@ out:
 }
 
 /*
+ * detect pci device, return 0 if it exists, or return 0
+ */
+int pci_device_detect(u8 bus, u8 dev, u8 func)
+{
+    u32 vendor;
+
+    vendor = pci_conf_read32(bus, dev, func, PCI_VENDOR_ID);
+    /* some broken boards return 0 or ~0 if a slot is empty: */
+    if ( (vendor == 0xffffffff) || (vendor == 0x00000000) ||
+         (vendor == 0x0000ffff) || (vendor == 0xffff0000) )
+        return 0;
+    return 1;
+}
+
+/*
  * scan pci devices to add all existed PCI devices to alldevs_list,
  * and setup pci hierarchy in array bus2bridge. This function is only
  * called in VT-d hardware setup
@@ -372,7 +387,6 @@ int __init scan_pci_devices(void)
     int bus, dev, func;
     u8 sec_bus, sub_bus;
     int type;
-    u32 l;
 
     spin_lock(&pcidevs_lock);
     for ( bus = 0; bus < 256; bus++ )
@@ -381,10 +395,7 @@ int __init scan_pci_devices(void)
         {
             for ( func = 0; func < 8; func++ )
             {
-                l = pci_conf_read32(bus, dev, func, PCI_VENDOR_ID);
-                /* some broken boards return 0 or ~0 if a slot is empty: */
-                if ( (l == 0xffffffff) || (l == 0x00000000) ||
-                     (l == 0x0000ffff) || (l == 0xffff0000) )
+                if ( pci_device_detect(bus, dev, func) == 0 )
                     continue;
 
                 pdev = alloc_pdev(bus, PCI_DEVFN(dev, func));
diff -r 104110651ff6 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Wed Jan 20 22:50:09 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 17:51:45 2010 +0800
@@ -410,14 +410,6 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent
     u64 base_addr = rmrr->base_address, end_addr = rmrr->end_address;
     int ret = 0;
 
-    if ( base_addr >= end_addr )
-    {
-        dprintk(XENLOG_ERR VTDPREFIX,
-                "RMRR error: base_addr %"PRIx64" end_address %"PRIx64"\n",
-                base_addr, end_addr);
-        return -EFAULT;
-    }
-
 #ifdef CONFIG_X86
     /* This check is here simply to detect when RMRR values are
      * not properly represented in the system memory map and
@@ -441,9 +433,6 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent
 
     rmrru->base_address = base_addr;
     rmrru->end_address = end_addr;
-    dprintk(XENLOG_INFO VTDPREFIX,
-            "  RMRR region: base_addr %"PRIx64" end_address %"PRIx64"\n",
-            rmrru->base_address, rmrru->end_address);
 
     dev_scope_start = (void *)(rmrr + 1);
     dev_scope_end   = ((void *)rmrr) + header->length;
@@ -453,7 +442,50 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent
     if ( ret || (rmrru->scope.devices_cnt == 0) )
         xfree(rmrru);
     else
-        acpi_register_rmrr_unit(rmrru);
+    {
+        u8 b, d, f;
+        int i, ignore = 0;
+
+        for ( i = 0; i < rmrru->scope.devices_cnt; i++ )
+        {
+            b = PCI_BUS(rmrru->scope.devices[i]);
+            d = PCI_SLOT(rmrru->scope.devices[i]);
+            f = PCI_FUNC(rmrru->scope.devices[i]);
+
+            if ( pci_device_detect(b, d, f) == 0 )
+                ignore = 1;
+            else
+            {
+                ignore = 0;
+                break;
+            }
+        }
+
+        if ( ignore )
+        {
+            dprintk(XENLOG_WARNING VTDPREFIX,
+                "  Ignore the RMRR (%"PRIx64", %"PRIx64") due to "
+                "devices under its scope are not PCI discoverable!\n",
+                rmrru->base_address, rmrru->end_address);
+            xfree(rmrru);
+        }
+        else if ( base_addr > end_addr )
+        {
+            dprintk(XENLOG_WARNING VTDPREFIX,
+                "  The RMRR (%"PRIx64", %"PRIx64") is incorrect!\n",
+                rmrru->base_address, rmrru->end_address);
+            xfree(rmrru);
+            ret = -EFAULT;
+        }
+        else
+        {
+            dprintk(XENLOG_INFO VTDPREFIX,
+                "  RMRR region: base_addr %"PRIx64" end_address %"PRIx64"\n",
+                rmrru->base_address, rmrru->end_address);
+            acpi_register_rmrr_unit(rmrru);
+        }
+    }
+
     return ret;
 }
 
diff -r 104110651ff6 xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Wed Jan 20 22:50:09 2010 +0800
+++ b/xen/include/xen/pci.h	Thu Jan 21 17:39:27 2010 +0800
@@ -74,6 +74,7 @@ enum {
     DEV_TYPE_PCI,
 };
 
+int pci_device_detect(u8 bus, u8 dev, u8 func);
 int scan_pci_devices(void);
 int pdev_type(u8 bus, u8 devfn);
 int find_upstream_bridge(u8 *bus, u8 *devfn, u8 *secbus);

[-- 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] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

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

Hi,

Some Q35 mainboard that has buggy BIOS, I have one of this,
reports invalid DRHD in addition to the invalid RMRR.

Attached patch fixes this DRHD issue in the same way as RMRR.
And also, I fixed RMRR validity checking loop.

Noboru.

Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>


-------- Original Message  --------
Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
From: Han, Weidong <weidong.han@intel.com>
To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com>
Date: Thu Jan 21 2010 11:46:12 GMT+0900

> Currently, Xen checks RMRR range and disables VT-d if RMRR range is set incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the device under its scope are not pci discoverable, because the RMRR won't be used by non-existed or disabled devices.
>
> This patch ignores the RMRR if the device under its scope are not pci discoverable, and only checks the validity of RMRRs that are actually used. In order to avoid duplicate pci device detection code, this patch defines a function pci_device_detect for it.
>
> Signed-off-by: Weidong Han<weidong.han@intel.com>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


[-- Attachment #2: 01_vtd-drhd-workaround.patch --]
[-- Type: text/plain, Size: 1086 bytes --]

diff -r bbad08b156e9 -r 072ffd2fa8f7 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 14:08:42 2010 +0900
+++ b/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 16:39:46 2010 +0900
@@ -397,7 +397,34 @@
     if ( ret )
         xfree(dmaru);
     else
-        acpi_register_drhd_unit(dmaru);
+    {
+        u8 b, d, f;
+        int i, ignore = 0;
+
+        for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
+        {
+            b = PCI_BUS(dmaru->scope.devices[i]);
+            d = PCI_SLOT(dmaru->scope.devices[i]);
+            f = PCI_FUNC(dmaru->scope.devices[i]);
+
+            if ( pci_device_detect(b, d, f) == 0 )
+            {
+                ignore = 1;
+                break;
+            }
+        }
+
+        if ( ignore )
+        {
+            dprintk(XENLOG_WARNING VTDPREFIX,
+                "  Ignore the DRHD due to "
+                "devices under its scope are not PCI discoverable!\n");
+            xfree(dmaru);
+        }
+        else
+            acpi_register_drhd_unit(dmaru);
+    }
+
     return ret;
 }
 

[-- Attachment #3: 02_vtd-rmrr-workaround-fix.patch --]
[-- Type: text/plain, Size: 499 bytes --]

diff -r 072ffd2fa8f7 -r 958f11b847cc xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 16:39:46 2010 +0900
+++ b/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 16:42:04 2010 +0900
@@ -480,10 +480,8 @@
             f = PCI_FUNC(rmrru->scope.devices[i]);
 
             if ( pci_device_detect(b, d, f) == 0 )
+            {
                 ignore = 1;
-            else
-            {
-                ignore = 0;
                 break;
             }
         }

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

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

RE: [PATCH] VT-d: improve RMRR validity checking

[Han, Weidong]

Hi Noboru,

You should not ignore DRHD even if devices under its scope are not pci discoverable. For the sake of security, we still enable these DRHDs but don't set any context mappings. In that case, any DMA that comes from these "supposedly disabled" devices will get blocked by VT-d, and hence avoid any security vulnerability with malicious s/w re-enabling these devices. 

You RMRR validity fixing is wrong. My RMRR patch is no problem. Pls note that the RMRR checking logic is:
	If all devices under RMRR's scope are not pci discoverable
		Ignore the RMRR
	Else if base_address > end_address
		Return error
	Else
		Register RMRR

Regards,
Weidong
		

-----Original Message-----
From: Noboru Iwamatsu [mailto:n_iwamatsu@jp.fujitsu.com] 
Sent: Thursday, January 21, 2010 4:26 PM
To: Han, Weidong
Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking

Hi,

Some Q35 mainboard that has buggy BIOS, I have one of this, reports invalid DRHD in addition to the invalid RMRR.

Attached patch fixes this DRHD issue in the same way as RMRR.
And also, I fixed RMRR validity checking loop.

Noboru.

Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>


-------- Original Message  --------
Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
From: Han, Weidong <weidong.han@intel.com>
To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com>
Date: Thu Jan 21 2010 11:46:12 GMT+0900

> Currently, Xen checks RMRR range and disables VT-d if RMRR range is set incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the device under its scope are not pci discoverable, because the RMRR won't be used by non-existed or disabled devices.
>
> This patch ignores the RMRR if the device under its scope are not pci discoverable, and only checks the validity of RMRRs that are actually used. In order to avoid duplicate pci device detection code, this patch defines a function pci_device_detect for it.
>
> Signed-off-by: Weidong Han<weidong.han@intel.com>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

Hi,

After registered invalid DRHDs, Xen hangs in boot time.

About RMRR, I understood the logic.
In my mainboard, unfortunately, RMRR has non-existent device under
its scope, and to make matters worse, the RMRR range is invalid.
So, I think RMRR that has no-existent device is valid.

How do you think about these?

> Hi Noboru,
>
> You should not ignore DRHD even if devices under its scope are not pci discoverable. For the sake of security, we still enable these DRHDs but don't set any context mappings. In that case, any DMA that comes from these "supposedly disabled" devices will get blocked by VT-d, and hence avoid any security vulnerability with malicious s/w re-enabling these devices.
>
> You RMRR validity fixing is wrong. My RMRR patch is no problem. Pls note that the RMRR checking logic is:
> 	If all devices under RMRR's scope are not pci discoverable
> 		Ignore the RMRR
> 	Else if base_address>  end_address
> 		Return error
> 	Else
> 		Register RMRR
>
> Regards,
> Weidong
> 		
>
> -----Original Message-----
> From: Noboru Iwamatsu [mailto:n_iwamatsu@jp.fujitsu.com]
> Sent: Thursday, January 21, 2010 4:26 PM
> To: Han, Weidong
> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com
> Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>
> Hi,
>
> Some Q35 mainboard that has buggy BIOS, I have one of this, reports invalid DRHD in addition to the invalid RMRR.
>
> Attached patch fixes this DRHD issue in the same way as RMRR.
> And also, I fixed RMRR validity checking loop.
>
> Noboru.
>
> Signed-off-by: Noboru Iwamatsu<n_iwamatsu@jp.fujitsu.com>
>
>
> -------- Original Message  --------
> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
> From: Han, Weidong<weidong.han@intel.com>
> To: xen-devel@lists.xensource.com<xen-devel@lists.xensource.com>
> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>
>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is set incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the device under its scope are not pci discoverable, because the RMRR won't be used by non-existed or disabled devices.
>>
>> This patch ignores the RMRR if the device under its scope are not pci discoverable, and only checks the validity of RMRRs that are actually used. In order to avoid duplicate pci device detection code, this patch defines a function pci_device_detect for it.
>>
>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

 > So, I think RMRR that has no-existent device is valid.

Sorry this is typo.
I mean:
So, I think RMRR that has no-existent device is "invalid"
and whole RMRR should be ignored.

Noboru.

> Hi,
>
> After registered invalid DRHDs, Xen hangs in boot time.
>
> About RMRR, I understood the logic.
> In my mainboard, unfortunately, RMRR has non-existent device under
> its scope, and to make matters worse, the RMRR range is invalid.
> So, I think RMRR that has no-existent device is valid.
>
> How do you think about these?
>
>> Hi Noboru,
>>
>> You should not ignore DRHD even if devices under its scope are not pci
>> discoverable. For the sake of security, we still enable these DRHDs
>> but don't set any context mappings. In that case, any DMA that comes
>> from these "supposedly disabled" devices will get blocked by VT-d, and
>> hence avoid any security vulnerability with malicious s/w re-enabling
>> these devices.
>>
>> You RMRR validity fixing is wrong. My RMRR patch is no problem. Pls
>> note that the RMRR checking logic is:
>> If all devices under RMRR's scope are not pci discoverable
>> Ignore the RMRR
>> Else if base_address> end_address
>> Return error
>> Else
>> Register RMRR
>>
>> Regards,
>> Weidong
>>
>>
>> -----Original Message-----
>> From: Noboru Iwamatsu [mailto:n_iwamatsu@jp.fujitsu.com]
>> Sent: Thursday, January 21, 2010 4:26 PM
>> To: Han, Weidong
>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com
>> Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>
>> Hi,
>>
>> Some Q35 mainboard that has buggy BIOS, I have one of this, reports
>> invalid DRHD in addition to the invalid RMRR.
>>
>> Attached patch fixes this DRHD issue in the same way as RMRR.
>> And also, I fixed RMRR validity checking loop.
>>
>> Noboru.
>>
>> Signed-off-by: Noboru Iwamatsu<n_iwamatsu@jp.fujitsu.com>
>>
>>
>> -------- Original Message --------
>> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>> From: Han, Weidong<weidong.han@intel.com>
>> To: xen-devel@lists.xensource.com<xen-devel@lists.xensource.com>
>> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>>
>>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is
>>> set incorrectly in BIOS rigorously. But, actually we can ignore the
>>> RMRR if the device under its scope are not pci discoverable, because
>>> the RMRR won't be used by non-existed or disabled devices.
>>>
>>> This patch ignores the RMRR if the device under its scope are not pci
>>> discoverable, and only checks the validity of RMRRs that are actually
>>> used. In order to avoid duplicate pci device detection code, this
>>> patch defines a function pci_device_detect for it.
>>>
>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Noboru Iwamatsu wrote:
>  > So, I think RMRR that has no-existent device is valid.
>
> Sorry this is typo.
> I mean:
> So, I think RMRR that has no-existent device is "invalid"
> and whole RMRR should be ignored.
>   
looks reasonable.

Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one 
patch?

Regards,
Weidong
> Noboru.
>
>   
>> Hi,
>>
>> After registered invalid DRHDs, Xen hangs in boot time.
>>
>> About RMRR, I understood the logic.
>> In my mainboard, unfortunately, RMRR has non-existent device under
>> its scope, and to make matters worse, the RMRR range is invalid.
>> So, I think RMRR that has no-existent device is valid.
>>
>> How do you think about these?
>>
>>     
>>> Hi Noboru,
>>>
>>> You should not ignore DRHD even if devices under its scope are not pci
>>> discoverable. For the sake of security, we still enable these DRHDs
>>> but don't set any context mappings. In that case, any DMA that comes
>>> from these "supposedly disabled" devices will get blocked by VT-d, and
>>> hence avoid any security vulnerability with malicious s/w re-enabling
>>> these devices.
>>>
>>> You RMRR validity fixing is wrong. My RMRR patch is no problem. Pls
>>> note that the RMRR checking logic is:
>>> If all devices under RMRR's scope are not pci discoverable
>>> Ignore the RMRR
>>> Else if base_address> end_address
>>> Return error
>>> Else
>>> Register RMRR
>>>
>>> Regards,
>>> Weidong
>>>
>>>
>>> -----Original Message-----
>>> From: Noboru Iwamatsu [mailto:n_iwamatsu@jp.fujitsu.com]
>>> Sent: Thursday, January 21, 2010 4:26 PM
>>> To: Han, Weidong
>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com
>>> Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>>
>>> Hi,
>>>
>>> Some Q35 mainboard that has buggy BIOS, I have one of this, reports
>>> invalid DRHD in addition to the invalid RMRR.
>>>
>>> Attached patch fixes this DRHD issue in the same way as RMRR.
>>> And also, I fixed RMRR validity checking loop.
>>>
>>> Noboru.
>>>
>>> Signed-off-by: Noboru Iwamatsu<n_iwamatsu@jp.fujitsu.com>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>> From: Han, Weidong<weidong.han@intel.com>
>>> To: xen-devel@lists.xensource.com<xen-devel@lists.xensource.com>
>>> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>>>
>>>       
>>>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is
>>>> set incorrectly in BIOS rigorously. But, actually we can ignore the
>>>> RMRR if the device under its scope are not pci discoverable, because
>>>> the RMRR won't be used by non-existed or disabled devices.
>>>>
>>>> This patch ignores the RMRR if the device under its scope are not pci
>>>> discoverable, and only checks the validity of RMRRs that are actually
>>>> used. In order to avoid duplicate pci device detection code, this
>>>> patch defines a function pci_device_detect for it.
>>>>
>>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>         
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>     
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Keir Fraser]

On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:

>> Sorry this is typo.
>> I mean:
>> So, I think RMRR that has no-existent device is "invalid"
>> and whole RMRR should be ignored.
>>   
> looks reasonable.
> 
> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
> patch?

Merge them up, re-send with both sign-off and acked-by all in one email.

 Thanks,
 Keir

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

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

Keir Fraser wrote:
> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>
>   
>>> Sorry this is typo.
>>> I mean:
>>> So, I think RMRR that has no-existent device is "invalid"
>>> and whole RMRR should be ignored.
>>>   
>>>       
>> looks reasonable.
>>
>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
>> patch?
>>     
>
> Merge them up, re-send with both sign-off and acked-by all in one email.
>
>  Thanks,
>  Keir
>
>   
Sorry, I disagree with Noboru after thinking it again. If the RMRR has 
both no-existent device and also has existent devices in its scope, we 
should not ignore it because the existent devices under its scope will 
be impacted without the RMRR. so I suggest to print a warning instead of 
ignore it. Attached a patch for it.

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

[-- Attachment #2: rmrr-warning.patch --]
[-- Type: text/plain, Size: 747 bytes --]

diff -r ea02c95af387 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 09:13:46 2010 +0000
+++ b/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 18:43:53 2010 +0800
@@ -453,7 +453,13 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent
             f = PCI_FUNC(rmrru->scope.devices[i]);
 
             if ( pci_device_detect(b, d, f) == 0 )
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  Non-existent device (%x:%x.%x) is reported "
+                    "in RMRR (%"PRIx64", %"PRIx64")'s scope!\n",
+                    b, d, f, rmrru->base_address, rmrru->end_address);
                 ignore = 1;
+            }
             else
             {
                 ignore = 0;

[-- 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] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

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

Hi Weidong,

I re-send the DRHD-fix patch.

If DRHD does not have existent devices, ignore it.
If DRHD has both existent and non-existent devices, consider it invalid
and not register.

According to this patch and yours, my machine successfully booted
with vt-d enabled.

Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>


> Keir Fraser wrote:
>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>
>>>> Sorry this is typo.
>>>> I mean:
>>>> So, I think RMRR that has no-existent device is "invalid"
>>>> and whole RMRR should be ignored.
>>> looks reasonable.
>>>
>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
>>> patch?
>>
>> Merge them up, re-send with both sign-off and acked-by all in one email.
>>
>> Thanks,
>> Keir
>>
> Sorry, I disagree with Noboru after thinking it again. If the RMRR has
> both no-existent device and also has existent devices in its scope, we
> should not ignore it because the existent devices under its scope will
> be impacted without the RMRR. so I suggest to print a warning instead of
> ignore it. Attached a patch for it.
>
> Signed-off-by: Weidong Han <weidong.han@intel.com>


[-- Attachment #2: vtd-drhd-fix-v2.patch --]
[-- Type: text/plain, Size: 1413 bytes --]

diff -r 2eee03873667 -r 65e84fc54aa5 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 21:06:50 2010 +0900
+++ b/xen/drivers/passthrough/vtd/dmar.c	Thu Jan 21 20:58:12 2010 +0900
@@ -397,7 +397,42 @@
     if ( ret )
         xfree(dmaru);
     else
-        acpi_register_drhd_unit(dmaru);
+    {
+        u8 b, d, f;
+        int i, invalid_cnt = 0;
+
+        for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
+        {
+            b = PCI_BUS(dmaru->scope.devices[i]);
+            d = PCI_SLOT(dmaru->scope.devices[i]);
+            f = PCI_FUNC(dmaru->scope.devices[i]);
+
+            if ( pci_device_detect(b, d, f) == 0 )
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  Non-existent device (%x:%x.%x) is reported "
+                    "in DRHD's scope!\n",
+                    b, d, f);
+                invalid_cnt++;
+            }
+        }
+
+        if ( invalid_cnt )
+        {
+            xfree(dmaru);
+            if ( invalid_cnt == dmaru->scope.devices_cnt )
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                "  Ignore the DRHD due to "
+                "devices under its scope are not PCI discoverable!\n");
+            }
+            else
+                ret = -EINVAL;
+        }
+        else
+            acpi_register_drhd_unit(dmaru);
+    }
+
     return ret;
 }
 

[-- 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] VT-d: improve RMRR validity checking

[Weidong Han]

Noboru Iwamatsu wrote:
> Hi Weidong,
>
> I re-send the DRHD-fix patch.
>
> If DRHD does not have existent devices, ignore it.
> If DRHD has both existent and non-existent devices, consider it invalid
> and not register.
>   

Although you patch workarounds your buggy BIOS, but we still need to 
enable it for security purpose as I mentioned in previous mail. We 
needn't workaround / fix all BIOS issues in software. I think security 
is more important for this specific BIOS issue. Did you report the BIOS 
issue to your OEM vendor? maybe it's better to get it fixed in BIOS.

Regards,
Weidong
> According to this patch and yours, my machine successfully booted
> with vt-d enabled.
>
> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>
>
>   
>> Keir Fraser wrote:
>>     
>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>
>>>       
>>>>> Sorry this is typo.
>>>>> I mean:
>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>> and whole RMRR should be ignored.
>>>>>           
>>>> looks reasonable.
>>>>
>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
>>>> patch?
>>>>         
>>> Merge them up, re-send with both sign-off and acked-by all in one email.
>>>
>>> Thanks,
>>> Keir
>>>
>>>       
>> Sorry, I disagree with Noboru after thinking it again. If the RMRR has
>> both no-existent device and also has existent devices in its scope, we
>> should not ignore it because the existent devices under its scope will
>> be impacted without the RMRR. so I suggest to print a warning instead of
>> ignore it. Attached a patch for it.
>>
>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>     
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Keir Fraser]

On 21/01/2010 12:46, "Weidong Han" <weidong.han@intel.com> wrote:

>> If DRHD does not have existent devices, ignore it.
>> If DRHD has both existent and non-existent devices, consider it invalid
>> and not register.
>>   
> 
> Although you patch workarounds your buggy BIOS, but we still need to
> enable it for security purpose as I mentioned in previous mail. We
> needn't workaround / fix all BIOS issues in software. I think security
> is more important for this specific BIOS issue. Did you report the BIOS
> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.

If VT-d cannot be correctly enabled on a particualr system, should we not
warn-and-disable (partially disable or completely disable) rather than fail
to boot? If we want to fail to boot, that is what the iommu=force option is
there for.

 -- Keir

Re: [PATCH] VT-d: improve RMRR validity checking

[Sander Eikelenboom]

Hello Weidong,

The problem is most vendor's just don't fix it and ignore the problem completely.
Most often hiding them selves behind: come back when it's a problem with Microsoft Windows, that the only single thing we support (and no other software, so no vmware, no xen, no linux, perhaps even no hypervisor)
Well I don't know if the virtual pc in windows 7 supports an iommu now, but it didn't in the past as far as i know, so any complain bounces off, and there it all seems to end for them.

Besides that i don't know if they do know what the problems with there implementation in BIOS is when someone reports it.
I think some behind the scenes pressure from Intel to vendors might help to solve some of them.
(my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for that) also suffers RMRR problem when another graphics card is inserted which switches off the IGD).

Although i think in my case your patch will work around that for me. Perhaps a third option is needed, which does all the workarounds possible and warns about potential security problem when requested ?

--
Sander






Thursday, January 21, 2010, 1:46:39 PM, you wrote:

> Noboru Iwamatsu wrote:
>> Hi Weidong,
>>
>> I re-send the DRHD-fix patch.
>>
>> If DRHD does not have existent devices, ignore it.
>> If DRHD has both existent and non-existent devices, consider it invalid
>> and not register.
>>   

> Although you patch workarounds your buggy BIOS, but we still need to 
> enable it for security purpose as I mentioned in previous mail. We 
> needn't workaround / fix all BIOS issues in software. I think security 
> is more important for this specific BIOS issue. Did you report the BIOS 
> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.

> Regards,
> Weidong
>> According to this patch and yours, my machine successfully booted
>> with vt-d enabled.
>>
>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>
>>
>>   
>>> Keir Fraser wrote:
>>>     
>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>>
>>>>       
>>>>>> Sorry this is typo.
>>>>>> I mean:
>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>> and whole RMRR should be ignored.
>>>>>>           
>>>>> looks reasonable.
>>>>>
>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
>>>>> patch?
>>>>>         
>>>> Merge them up, re-send with both sign-off and acked-by all in one email.
>>>>
>>>> Thanks,
>>>> Keir
>>>>
>>>>       
>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR has
>>> both no-existent device and also has existent devices in its scope, we
>>> should not ignore it because the existent devices under its scope will
>>> be impacted without the RMRR. so I suggest to print a warning instead of
>>> ignore it. Attached a patch for it.
>>>
>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>     
>>
>>   






-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

Re: [PATCH] VT-d: improve RMRR validity checking

[Keir Fraser]

If we want to keep iommu=1 as default, then it is unacceptable to fail to
boot on a fairly wide range of modern systems. We have to warn-and-disable,
partially or completely, unless iommu=force is specified. Or we need to
revert to iommu=0 as the default.

What do you think, Weidong?

 -- Keir

On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

> Hello Weidong,
> 
> The problem is most vendor's just don't fix it and ignore the problem
> completely.
> Most often hiding them selves behind: come back when it's a problem with
> Microsoft Windows, that the only single thing we support (and no other
> software, so no vmware, no xen, no linux, perhaps even no hypervisor)
> Well I don't know if the virtual pc in windows 7 supports an iommu now, but it
> didn't in the past as far as i know, so any complain bounces off, and there it
> all seems to end for them.
> 
> Besides that i don't know if they do know what the problems with there
> implementation in BIOS is when someone reports it.
> I think some behind the scenes pressure from Intel to vendors might help to
> solve some of them.
> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for that) also
> suffers RMRR problem when another graphics card is inserted which switches off
> the IGD).
> 
> Although i think in my case your patch will work around that for me. Perhaps a
> third option is needed, which does all the workarounds possible and warns
> about potential security problem when requested ?
> 
> --
> Sander
> 
> 
> 
> 
> 
> 
> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
> 
>> Noboru Iwamatsu wrote:
>>> Hi Weidong,
>>> 
>>> I re-send the DRHD-fix patch.
>>> 
>>> If DRHD does not have existent devices, ignore it.
>>> If DRHD has both existent and non-existent devices, consider it invalid
>>> and not register.
>>>   
> 
>> Although you patch workarounds your buggy BIOS, but we still need to
>> enable it for security purpose as I mentioned in previous mail. We
>> needn't workaround / fix all BIOS issues in software. I think security
>> is more important for this specific BIOS issue. Did you report the BIOS
>> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.
> 
>> Regards,
>> Weidong
>>> According to this patch and yours, my machine successfully booted
>>> with vt-d enabled.
>>> 
>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>> 
>>> 
>>>   
>>>> Keir Fraser wrote:
>>>>     
>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>>> 
>>>>>       
>>>>>>> Sorry this is typo.
>>>>>>> I mean:
>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>> and whole RMRR should be ignored.
>>>>>>>           
>>>>>> looks reasonable.
>>>>>> 
>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
>>>>>> patch?
>>>>>>         
>>>>> Merge them up, re-send with both sign-off and acked-by all in one email.
>>>>> 
>>>>> Thanks,
>>>>> Keir
>>>>> 
>>>>>       
>>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR has
>>>> both no-existent device and also has existent devices in its scope, we
>>>> should not ignore it because the existent devices under its scope will
>>>> be impacted without the RMRR. so I suggest to print a warning instead of
>>>> ignore it. Attached a patch for it.
>>>> 
>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>     
>>> 
>>>   
> 
> 
> 
> 
> 

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Keir Fraser wrote:
> If we want to keep iommu=1 as default, then it is unacceptable to fail to
> boot on a fairly wide range of modern systems. We have to warn-and-disable,
> partially or completely, unless iommu=force is specified. Or we need to
> revert to iommu=0 as the default.
>
> What do you think, Weidong?
>   
Yes. I agree to warn-and-disable for these BIOS issues, and consider 
security more when iommu=force. Therefore I will implement a patch based 
on Nororu's patch.

Regards,
Weidong

>  -- Keir
>
> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>
>   
>> Hello Weidong,
>>
>> The problem is most vendor's just don't fix it and ignore the problem
>> completely.
>> Most often hiding them selves behind: come back when it's a problem with
>> Microsoft Windows, that the only single thing we support (and no other
>> software, so no vmware, no xen, no linux, perhaps even no hypervisor)
>> Well I don't know if the virtual pc in windows 7 supports an iommu now, but it
>> didn't in the past as far as i know, so any complain bounces off, and there it
>> all seems to end for them.
>>
>> Besides that i don't know if they do know what the problems with there
>> implementation in BIOS is when someone reports it.
>> I think some behind the scenes pressure from Intel to vendors might help to
>> solve some of them.
>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for that) also
>> suffers RMRR problem when another graphics card is inserted which switches off
>> the IGD).
>>
>> Although i think in my case your patch will work around that for me. Perhaps a
>> third option is needed, which does all the workarounds possible and warns
>> about potential security problem when requested ?
>>
>> --
>> Sander
>>
>>
>>
>>
>>
>>
>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>
>>     
>>> Noboru Iwamatsu wrote:
>>>       
>>>> Hi Weidong,
>>>>
>>>> I re-send the DRHD-fix patch.
>>>>
>>>> If DRHD does not have existent devices, ignore it.
>>>> If DRHD has both existent and non-existent devices, consider it invalid
>>>> and not register.
>>>>   
>>>>         
>>> Although you patch workarounds your buggy BIOS, but we still need to
>>> enable it for security purpose as I mentioned in previous mail. We
>>> needn't workaround / fix all BIOS issues in software. I think security
>>> is more important for this specific BIOS issue. Did you report the BIOS
>>> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.
>>>       
>>> Regards,
>>> Weidong
>>>       
>>>> According to this patch and yours, my machine successfully booted
>>>> with vt-d enabled.
>>>>
>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>
>>>>
>>>>   
>>>>         
>>>>> Keir Fraser wrote:
>>>>>     
>>>>>           
>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>>>>
>>>>>>       
>>>>>>             
>>>>>>>> Sorry this is typo.
>>>>>>>> I mean:
>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>           
>>>>>>>>                 
>>>>>>> looks reasonable.
>>>>>>>
>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
>>>>>>> patch?
>>>>>>>         
>>>>>>>               
>>>>>> Merge them up, re-send with both sign-off and acked-by all in one email.
>>>>>>
>>>>>> Thanks,
>>>>>> Keir
>>>>>>
>>>>>>       
>>>>>>             
>>>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR has
>>>>> both no-existent device and also has existent devices in its scope, we
>>>>> should not ignore it because the existent devices under its scope will
>>>>> be impacted without the RMRR. so I suggest to print a warning instead of
>>>>> ignore it. Attached a patch for it.
>>>>>
>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>     
>>>>>           
>>>>   
>>>>         
>>
>>
>>
>>     
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

Hi Weidong,

I'm not sure why the security problem is caused by ignoring
the DRHD that has only non-existent devices.

Could you explain details or where to read the spec?

As you saying, security is the top-priority.
However, when iommu=force is specified, we should enable vt-d
if there are some potential issues.
Because users want to "force" anyway.

Regards,
Noboru.

> Keir Fraser wrote:
>> If we want to keep iommu=1 as default, then it is unacceptable to fail to
>> boot on a fairly wide range of modern systems. We have to
>> warn-and-disable,
>> partially or completely, unless iommu=force is specified. Or we need to
>> revert to iommu=0 as the default.
>>
>> What do you think, Weidong?
> Yes. I agree to warn-and-disable for these BIOS issues, and consider
> security more when iommu=force. Therefore I will implement a patch based
> on Nororu's patch.
>
> Regards,
> Weidong
>
>> -- Keir
>>
>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>
>>> Hello Weidong,
>>>
>>> The problem is most vendor's just don't fix it and ignore the problem
>>> completely.
>>> Most often hiding them selves behind: come back when it's a problem with
>>> Microsoft Windows, that the only single thing we support (and no other
>>> software, so no vmware, no xen, no linux, perhaps even no hypervisor)
>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>> now, but it
>>> didn't in the past as far as i know, so any complain bounces off, and
>>> there it
>>> all seems to end for them.
>>>
>>> Besides that i don't know if they do know what the problems with there
>>> implementation in BIOS is when someone reports it.
>>> I think some behind the scenes pressure from Intel to vendors might
>>> help to
>>> solve some of them.
>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>> that) also
>>> suffers RMRR problem when another graphics card is inserted which
>>> switches off
>>> the IGD).
>>>
>>> Although i think in my case your patch will work around that for me.
>>> Perhaps a
>>> third option is needed, which does all the workarounds possible and
>>> warns
>>> about potential security problem when requested ?
>>>
>>> --
>>> Sander
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>
>>>> Noboru Iwamatsu wrote:
>>>>> Hi Weidong,
>>>>>
>>>>> I re-send the DRHD-fix patch.
>>>>>
>>>>> If DRHD does not have existent devices, ignore it.
>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>> invalid
>>>>> and not register.
>>>> Although you patch workarounds your buggy BIOS, but we still need to
>>>> enable it for security purpose as I mentioned in previous mail. We
>>>> needn't workaround / fix all BIOS issues in software. I think security
>>>> is more important for this specific BIOS issue. Did you report the BIOS
>>>> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.
>>>> Regards,
>>>> Weidong
>>>>> According to this patch and yours, my machine successfully booted
>>>>> with vt-d enabled.
>>>>>
>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>
>>>>>
>>>>>> Keir Fraser wrote:
>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>>>>>
>>>>>>>>> Sorry this is typo.
>>>>>>>>> I mean:
>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>> looks reasonable.
>>>>>>>>
>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>> them to one
>>>>>>>> patch?
>>>>>>> Merge them up, re-send with both sign-off and acked-by all in one
>>>>>>> email.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Keir
>>>>>>>
>>>>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR
>>>>>> has
>>>>>> both no-existent device and also has existent devices in its
>>>>>> scope, we
>>>>>> should not ignore it because the existent devices under its scope
>>>>>> will
>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>> instead of
>>>>>> ignore it. Attached a patch for it.
>>>>>>
>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>
>>>
>>>
>>
>>
>

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Noboru Iwamatsu wrote:
> Hi Weidong,
>
> I'm not sure why the security problem is caused by ignoring
> the DRHD that has only non-existent devices.
>
> Could you explain details or where to read the spec?
>   

 It's requested from security experts. The device that is not pci 
discoverable may be re-enabled by malicious software. If its DRHD is not 
enabled, the re-enabled device is not protected by VT-d. It will cause 
security issue.

> As you saying, security is the top-priority.
> However, when iommu=force is specified, we should enable vt-d
> if there are some potential issues.
> Because users want to "force" anyway.
>   
iommu=force was introduced to enable VT-d anyway for security purpose. I 
plan to still enable those DRHDs that includes non-existed device when 
iommu=force, otherwise ignore them.

Regards,
Weidong
> Regards,
> Noboru.
>
>   
>> Keir Fraser wrote:
>>     
>>> If we want to keep iommu=1 as default, then it is unacceptable to fail to
>>> boot on a fairly wide range of modern systems. We have to
>>> warn-and-disable,
>>> partially or completely, unless iommu=force is specified. Or we need to
>>> revert to iommu=0 as the default.
>>>
>>> What do you think, Weidong?
>>>       
>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>> security more when iommu=force. Therefore I will implement a patch based
>> on Nororu's patch.
>>
>> Regards,
>> Weidong
>>
>>     
>>> -- Keir
>>>
>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>>
>>>       
>>>> Hello Weidong,
>>>>
>>>> The problem is most vendor's just don't fix it and ignore the problem
>>>> completely.
>>>> Most often hiding them selves behind: come back when it's a problem with
>>>> Microsoft Windows, that the only single thing we support (and no other
>>>> software, so no vmware, no xen, no linux, perhaps even no hypervisor)
>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>> now, but it
>>>> didn't in the past as far as i know, so any complain bounces off, and
>>>> there it
>>>> all seems to end for them.
>>>>
>>>> Besides that i don't know if they do know what the problems with there
>>>> implementation in BIOS is when someone reports it.
>>>> I think some behind the scenes pressure from Intel to vendors might
>>>> help to
>>>> solve some of them.
>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>> that) also
>>>> suffers RMRR problem when another graphics card is inserted which
>>>> switches off
>>>> the IGD).
>>>>
>>>> Although i think in my case your patch will work around that for me.
>>>> Perhaps a
>>>> third option is needed, which does all the workarounds possible and
>>>> warns
>>>> about potential security problem when requested ?
>>>>
>>>> --
>>>> Sander
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>
>>>>         
>>>>> Noboru Iwamatsu wrote:
>>>>>           
>>>>>> Hi Weidong,
>>>>>>
>>>>>> I re-send the DRHD-fix patch.
>>>>>>
>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>> invalid
>>>>>> and not register.
>>>>>>             
>>>>> Although you patch workarounds your buggy BIOS, but we still need to
>>>>> enable it for security purpose as I mentioned in previous mail. We
>>>>> needn't workaround / fix all BIOS issues in software. I think security
>>>>> is more important for this specific BIOS issue. Did you report the BIOS
>>>>> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.
>>>>> Regards,
>>>>> Weidong
>>>>>           
>>>>>> According to this patch and yours, my machine successfully booted
>>>>>> with vt-d enabled.
>>>>>>
>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Keir Fraser wrote:
>>>>>>>               
>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>>>>>>
>>>>>>>>                 
>>>>>>>>>> Sorry this is typo.
>>>>>>>>>> I mean:
>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>                     
>>>>>>>>> looks reasonable.
>>>>>>>>>
>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>> them to one
>>>>>>>>> patch?
>>>>>>>>>                   
>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in one
>>>>>>>> email.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Keir
>>>>>>>>
>>>>>>>>                 
>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR
>>>>>>> has
>>>>>>> both no-existent device and also has existent devices in its
>>>>>>> scope, we
>>>>>>> should not ignore it because the existent devices under its scope
>>>>>>> will
>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>> instead of
>>>>>>> ignore it. Attached a patch for it.
>>>>>>>
>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>>>               
>>>>
>>>>         
>>>       
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

Thanks,

I understood.

> Noboru Iwamatsu wrote:
>> Hi Weidong,
>>
>> I'm not sure why the security problem is caused by ignoring
>> the DRHD that has only non-existent devices.
>>
>> Could you explain details or where to read the spec?
>
> It's requested from security experts. The device that is not pci
> discoverable may be re-enabled by malicious software. If its DRHD is not
> enabled, the re-enabled device is not protected by VT-d. It will cause
> security issue.
>
>> As you saying, security is the top-priority.
>> However, when iommu=force is specified, we should enable vt-d
>> if there are some potential issues.
>> Because users want to "force" anyway.
> iommu=force was introduced to enable VT-d anyway for security purpose. I
> plan to still enable those DRHDs that includes non-existed device when
> iommu=force, otherwise ignore them.
>
> Regards,
> Weidong
>> Regards,
>> Noboru.
>>
>>> Keir Fraser wrote:
>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>> fail to
>>>> boot on a fairly wide range of modern systems. We have to
>>>> warn-and-disable,
>>>> partially or completely, unless iommu=force is specified. Or we need to
>>>> revert to iommu=0 as the default.
>>>>
>>>> What do you think, Weidong?
>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>> security more when iommu=force. Therefore I will implement a patch based
>>> on Nororu's patch.
>>>
>>> Regards,
>>> Weidong
>>>
>>>> -- Keir
>>>>
>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>>>
>>>>> Hello Weidong,
>>>>>
>>>>> The problem is most vendor's just don't fix it and ignore the problem
>>>>> completely.
>>>>> Most often hiding them selves behind: come back when it's a problem
>>>>> with
>>>>> Microsoft Windows, that the only single thing we support (and no other
>>>>> software, so no vmware, no xen, no linux, perhaps even no hypervisor)
>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>> now, but it
>>>>> didn't in the past as far as i know, so any complain bounces off, and
>>>>> there it
>>>>> all seems to end for them.
>>>>>
>>>>> Besides that i don't know if they do know what the problems with there
>>>>> implementation in BIOS is when someone reports it.
>>>>> I think some behind the scenes pressure from Intel to vendors might
>>>>> help to
>>>>> solve some of them.
>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>> that) also
>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>> switches off
>>>>> the IGD).
>>>>>
>>>>> Although i think in my case your patch will work around that for me.
>>>>> Perhaps a
>>>>> third option is needed, which does all the workarounds possible and
>>>>> warns
>>>>> about potential security problem when requested ?
>>>>>
>>>>> --
>>>>> Sander
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>
>>>>>> Noboru Iwamatsu wrote:
>>>>>>> Hi Weidong,
>>>>>>>
>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>
>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>> invalid
>>>>>>> and not register.
>>>>>> Although you patch workarounds your buggy BIOS, but we still need to
>>>>>> enable it for security purpose as I mentioned in previous mail. We
>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>> security
>>>>>> is more important for this specific BIOS issue. Did you report the
>>>>>> BIOS
>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.
>>>>>> Regards,
>>>>>> Weidong
>>>>>>> According to this patch and yours, my machine successfully booted
>>>>>>> with vt-d enabled.
>>>>>>>
>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>
>>>>>>>
>>>>>>>> Keir Fraser wrote:
>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>>>>>>>
>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>> I mean:
>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>> looks reasonable.
>>>>>>>>>>
>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>> them to one
>>>>>>>>>> patch?
>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in one
>>>>>>>>> email.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Keir
>>>>>>>>>
>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR
>>>>>>>> has
>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>> scope, we
>>>>>>>> should not ignore it because the existent devices under its scope
>>>>>>>> will
>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>> instead of
>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>
>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>
>>
>>
>

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

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

I implemented a patch and attached.

patch description:
    In order to make Xen more defensive to VT-d related BIOS issue, this 
patch ignores a DRHD if all devices under its scope are not pci 
discoverable, and regards a DRHD as invalid and then disable whole VT-d 
if some devices under its scope are not pci discoverable. But if 
iommu=force is set, it will enable all DRHDs reported by BIOS, to avoid 
any security vulnerability with malicious s/s re-enabling "supposed 
disabled" devices.  Pls note that we don't know the devices under the 
"Include_all" DRHD are existent or not, because the scope of 
"Include_all" DRHD  won't enumerate common pci device, it only 
enumerates I/OxAPIC and HPET devices.

Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
Signed-off-by: Weidong Han <weidong.han@intel.com>


Noboru, pls test the patch on your machine?

Joe, could you review the patch? and pls ACK it if it's fine for you.

Regards,
Weidong

Noboru Iwamatsu wrote:
> Thanks,
>
> I understood.
>
>   
>> Noboru Iwamatsu wrote:
>>     
>>> Hi Weidong,
>>>
>>> I'm not sure why the security problem is caused by ignoring
>>> the DRHD that has only non-existent devices.
>>>
>>> Could you explain details or where to read the spec?
>>>       
>> It's requested from security experts. The device that is not pci
>> discoverable may be re-enabled by malicious software. If its DRHD is not
>> enabled, the re-enabled device is not protected by VT-d. It will cause
>> security issue.
>>
>>     
>>> As you saying, security is the top-priority.
>>> However, when iommu=force is specified, we should enable vt-d
>>> if there are some potential issues.
>>> Because users want to "force" anyway.
>>>       
>> iommu=force was introduced to enable VT-d anyway for security purpose. I
>> plan to still enable those DRHDs that includes non-existed device when
>> iommu=force, otherwise ignore them.
>>
>> Regards,
>> Weidong
>>     
>>> Regards,
>>> Noboru.
>>>
>>>       
>>>> Keir Fraser wrote:
>>>>         
>>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>>> fail to
>>>>> boot on a fairly wide range of modern systems. We have to
>>>>> warn-and-disable,
>>>>> partially or completely, unless iommu=force is specified. Or we need to
>>>>> revert to iommu=0 as the default.
>>>>>
>>>>> What do you think, Weidong?
>>>>>           
>>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>>> security more when iommu=force. Therefore I will implement a patch based
>>>> on Nororu's patch.
>>>>
>>>> Regards,
>>>> Weidong
>>>>
>>>>         
>>>>> -- Keir
>>>>>
>>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>>>>
>>>>>           
>>>>>> Hello Weidong,
>>>>>>
>>>>>> The problem is most vendor's just don't fix it and ignore the problem
>>>>>> completely.
>>>>>> Most often hiding them selves behind: come back when it's a problem
>>>>>> with
>>>>>> Microsoft Windows, that the only single thing we support (and no other
>>>>>> software, so no vmware, no xen, no linux, perhaps even no hypervisor)
>>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>>> now, but it
>>>>>> didn't in the past as far as i know, so any complain bounces off, and
>>>>>> there it
>>>>>> all seems to end for them.
>>>>>>
>>>>>> Besides that i don't know if they do know what the problems with there
>>>>>> implementation in BIOS is when someone reports it.
>>>>>> I think some behind the scenes pressure from Intel to vendors might
>>>>>> help to
>>>>>> solve some of them.
>>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>>> that) also
>>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>>> switches off
>>>>>> the IGD).
>>>>>>
>>>>>> Although i think in my case your patch will work around that for me.
>>>>>> Perhaps a
>>>>>> third option is needed, which does all the workarounds possible and
>>>>>> warns
>>>>>> about potential security problem when requested ?
>>>>>>
>>>>>> --
>>>>>> Sander
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>>
>>>>>>             
>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>               
>>>>>>>> Hi Weidong,
>>>>>>>>
>>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>>
>>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>>> invalid
>>>>>>>> and not register.
>>>>>>>>                 
>>>>>>> Although you patch workarounds your buggy BIOS, but we still need to
>>>>>>> enable it for security purpose as I mentioned in previous mail. We
>>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>>> security
>>>>>>> is more important for this specific BIOS issue. Did you report the
>>>>>>> BIOS
>>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.
>>>>>>> Regards,
>>>>>>> Weidong
>>>>>>>               
>>>>>>>> According to this patch and yours, my machine successfully booted
>>>>>>>> with vt-d enabled.
>>>>>>>>
>>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>                   
>>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>>> I mean:
>>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>>>                         
>>>>>>>>>>> looks reasonable.
>>>>>>>>>>>
>>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>>> them to one
>>>>>>>>>>> patch?
>>>>>>>>>>>                       
>>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in one
>>>>>>>>>> email.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Keir
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR
>>>>>>>>> has
>>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>>> scope, we
>>>>>>>>> should not ignore it because the existent devices under its scope
>>>>>>>>> will
>>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>>> instead of
>>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>>>>>                   
>>>       
>
>
>   


[-- Attachment #2: drhd-ignore.patch --]
[-- Type: text/plain, Size: 1744 bytes --]

diff -r 207fba95a7d5 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Fri Jan 22 13:12:45 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c	Fri Jan 22 22:32:10 2010 +0800
@@ -396,8 +396,49 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
 
     if ( ret )
         xfree(dmaru);
+    else if ( force_iommu || dmaru->include_all )
+        acpi_register_drhd_unit(dmaru);
     else
-        acpi_register_drhd_unit(dmaru);
+    {
+        u8 b, d, f;
+        int i, invalid_cnt = 0;
+
+        for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
+        {
+            b = PCI_BUS(dmaru->scope.devices[i]);
+            d = PCI_SLOT(dmaru->scope.devices[i]);
+            f = PCI_FUNC(dmaru->scope.devices[i]);
+
+            if ( pci_device_detect(b, d, f) == 0 )
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  Non-existent device (%x:%x.%x) is reported "
+                    "in this DRHD's scope!\n", b, d, f);
+                invalid_cnt++;
+            }
+        }
+
+        if ( invalid_cnt )
+        {
+            xfree(dmaru);
+            if ( invalid_cnt == dmaru->scope.devices_cnt )
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  Ignore the DRHD due to all devices under "
+                    "its scope are not PCI discoverable!\n");
+            }
+            else
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  The DRHD is invalid due to some devices under "
+                    "its scope are not PCI discoverable!\n");
+                ret = -EINVAL;
+            }
+        }
+        else
+            acpi_register_drhd_unit(dmaru);
+    }
+
     return ret;
 }
 

[-- 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] VT-d: improve RMRR validity checking

[Sander Eikelenboom]

Hello Weidong,

Wouldn't it be more clear to add an option to iommu= for this case ?

if iommu=on,..,..,security

With the security option specified:
     -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
     -warn,fail or panic incase it can't enable all to enforce the security.

Without the security option specified (default)
     - it tries to work as with the security option specified
     - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
     - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
     - and keep vt-d enabled


Regards,

Sander



Friday, January 22, 2010, 9:47:11 AM, you wrote:

> diff -r 207fba95a7d5 xen/drivers/passthrough/vtd/dmar.c
> --- a/xen/drivers/passthrough/vtd/dmar.c        Fri Jan 22 13:12:45 2010 +0800
> +++ b/xen/drivers/passthrough/vtd/dmar.c        Fri Jan 22 22:32:10 2010 +0800
> @@ -396,8 +396,49 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
>  
>      if ( ret )
>          xfree(dmaru);
> +    else if ( force_iommu || dmaru->include_all )
> +        acpi_register_drhd_unit(dmaru);
>      else
> -        acpi_register_drhd_unit(dmaru);
> +    {
> +        u8 b, d, f;
> +        int i, invalid_cnt = 0;
> +
> +        for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
> +        {
> +            b = PCI_BUS(dmaru->scope.devices[i]);
> +            d = PCI_SLOT(dmaru->scope.devices[i]);
> +            f = PCI_FUNC(dmaru->scope.devices[i]);
> +
> +            if ( pci_device_detect(b, d, f) == 0 )
> +            {
> +                dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "  Non-existent device (%x:%x.%x) is reported "
> +                    "in this DRHD's scope!\n", b, d, f);
> +                invalid_cnt++;
> +            }
> +        }
> +
> +        if ( invalid_cnt )
> +        {
> +            xfree(dmaru);
> +            if ( invalid_cnt == dmaru->scope.devices_cnt )
> +            {
> +                dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "  Ignore the DRHD due to all devices under "
> +                    "its scope are not PCI discoverable!\n");
> +            }
> +            else
> +            {
> +                dprintk(XENLOG_WARNING VTDPREFIX,
> +                    "  The DRHD is invalid due to some devices under "
> +                    "its scope are not PCI discoverable!\n");
> +                ret = -EINVAL;
> +            }
> +        }
> +        else
> +            acpi_register_drhd_unit(dmaru);
> +    }
> +
>      return ret;
>  }
>  



-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Sander Eikelenboom wrote:
> Hello Weidong,
>
> Wouldn't it be more clear to add an option to iommu= for this case ?
>
> if iommu=on,..,..,security
>
> With the security option specified:
>      -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
>      -warn,fail or panic incase it can't enable all to enforce the security.
>   
iommu=force is for security. It does as you described above. So I think 
"security" option is not necessary.
> Without the security option specified (default)
>      - it tries to work as with the security option specified
>      - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
>      - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
>      - and keep vt-d enabled
>
>   
the default iommu=1 works like iommu=force if BIOS is correct. But in 
fact we encountered some buggy BIOS, and then we added some workarounds 
to make VT-d still be enabled,  or warn and disable VT-d if the issue is 
regarded as invalid and cannot be workarounded. These workarounds make 
Xen more defensive to VT-d BIOS issues. The panic only occurs when 
operating VT-d hardware fails, because it means the hardware is possibly 
malfunctional.

In short, default iommu=1 can workaround known VT-d BIOS issues we 
observed till now, while iommu=force ensures best security provided by VT-d.

Regards,
Weidong

> Regards,
>
> Sander
>
>
>
> Friday, January 22, 2010, 9:47:11 AM, you wrote:
>
>   
>> diff -r 207fba95a7d5 xen/drivers/passthrough/vtd/dmar.c
>> --- a/xen/drivers/passthrough/vtd/dmar.c        Fri Jan 22 13:12:45 2010 +0800
>> +++ b/xen/drivers/passthrough/vtd/dmar.c        Fri Jan 22 22:32:10 2010 +0800
>> @@ -396,8 +396,49 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
>>  
>>      if ( ret )
>>          xfree(dmaru);
>> +    else if ( force_iommu || dmaru->include_all )
>> +        acpi_register_drhd_unit(dmaru);
>>      else
>> -        acpi_register_drhd_unit(dmaru);
>> +    {
>> +        u8 b, d, f;
>> +        int i, invalid_cnt = 0;
>> +
>> +        for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
>> +        {
>> +            b = PCI_BUS(dmaru->scope.devices[i]);
>> +            d = PCI_SLOT(dmaru->scope.devices[i]);
>> +            f = PCI_FUNC(dmaru->scope.devices[i]);
>> +
>> +            if ( pci_device_detect(b, d, f) == 0 )
>> +            {
>> +                dprintk(XENLOG_WARNING VTDPREFIX,
>> +                    "  Non-existent device (%x:%x.%x) is reported "
>> +                    "in this DRHD's scope!\n", b, d, f);
>> +                invalid_cnt++;
>> +            }
>> +        }
>> +
>> +        if ( invalid_cnt )
>> +        {
>> +            xfree(dmaru);
>> +            if ( invalid_cnt == dmaru->scope.devices_cnt )
>> +            {
>> +                dprintk(XENLOG_WARNING VTDPREFIX,
>> +                    "  Ignore the DRHD due to all devices under "
>> +                    "its scope are not PCI discoverable!\n");
>> +            }
>> +            else
>> +            {
>> +                dprintk(XENLOG_WARNING VTDPREFIX,
>> +                    "  The DRHD is invalid due to some devices under "
>> +                    "its scope are not PCI discoverable!\n");
>> +                ret = -EINVAL;
>> +            }
>> +        }
>> +        else
>> +            acpi_register_drhd_unit(dmaru);
>> +    }
>> +
>>      return ret;
>>  }
>>  
>>     
>
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Pasi Kärkkäinen]

On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
> Sander Eikelenboom wrote:
>> Hello Weidong,
>>
>> Wouldn't it be more clear to add an option to iommu= for this case ?
>>
>> if iommu=on,..,..,security
>>
>> With the security option specified:
>>      -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
>>      -warn,fail or panic incase it can't enable all to enforce the security.
>>   
> iommu=force is for security. It does as you described above. So I think  
> "security" option is not necessary.
>> Without the security option specified (default)
>>      - it tries to work as with the security option specified
>>      - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
>>      - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
>>      - and keep vt-d enabled
>>
>>   
> the default iommu=1 works like iommu=force if BIOS is correct. But in  
> fact we encountered some buggy BIOS, and then we added some workarounds  
> to make VT-d still be enabled,  or warn and disable VT-d if the issue is  
> regarded as invalid and cannot be workarounded. These workarounds make  
> Xen more defensive to VT-d BIOS issues. The panic only occurs when  
> operating VT-d hardware fails, because it means the hardware is possibly  
> malfunctional.
>
> In short, default iommu=1 can workaround known VT-d BIOS issues we  
> observed till now, while iommu=force ensures best security provided by 
> VT-d.
>

So the default iommu=1 might be insecure? And iommu=force is always secure? 

To me "force" sounds like it makes it work always, no matter if it's secure or not..

-- Pasi

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Pasi Kärkkäinen wrote:
> On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
>   
>> Sander Eikelenboom wrote:
>>     
>>> Hello Weidong,
>>>
>>> Wouldn't it be more clear to add an option to iommu= for this case ?
>>>
>>> if iommu=on,..,..,security
>>>
>>> With the security option specified:
>>>      -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
>>>      -warn,fail or panic incase it can't enable all to enforce the security.
>>>   
>>>       
>> iommu=force is for security. It does as you described above. So I think  
>> "security" option is not necessary.
>>     
>>> Without the security option specified (default)
>>>      - it tries to work as with the security option specified
>>>      - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
>>>      - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
>>>      - and keep vt-d enabled
>>>
>>>   
>>>       
>> the default iommu=1 works like iommu=force if BIOS is correct. But in  
>> fact we encountered some buggy BIOS, and then we added some workarounds  
>> to make VT-d still be enabled,  or warn and disable VT-d if the issue is  
>> regarded as invalid and cannot be workarounded. These workarounds make  
>> Xen more defensive to VT-d BIOS issues. The panic only occurs when  
>> operating VT-d hardware fails, because it means the hardware is possibly  
>> malfunctional.
>>
>> In short, default iommu=1 can workaround known VT-d BIOS issues we  
>> observed till now, while iommu=force ensures best security provided by 
>> VT-d.
>>
>>     
>
> So the default iommu=1 might be insecure? And iommu=force is always secure? 
>
> To me "force" sounds like it makes it work always, no matter if it's secure or not..
>   
The "security" here means the protection provided VT-d. The main 
difference between them is iommu=force tries to enable all VT-d units in 
any case, if any VT-d unit cannot enabled, it will quit Xen booting 
(panic), thus it guarantees security provided by VT-d. while when 
iommu=1, in order to workaround some BIOS issues, it will ignore some 
invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d. 

Regards,
Weidong

Re: [PATCH] VT-d: improve RMRR validity checking

[Pasi Kärkkäinen]

On Sat, Jan 23, 2010 at 08:40:10PM +0800, Weidong Han wrote:
> Pasi Kärkkäinen wrote:
>> On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
>>   
>>> Sander Eikelenboom wrote:
>>>     
>>>> Hello Weidong,
>>>>
>>>> Wouldn't it be more clear to add an option to iommu= for this case ?
>>>>
>>>> if iommu=on,..,..,security
>>>>
>>>> With the security option specified:
>>>>      -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
>>>>      -warn,fail or panic incase it can't enable all to enforce the security.
>>>>         
>>> iommu=force is for security. It does as you described above. So I 
>>> think  "security" option is not necessary.
>>>     
>>>> Without the security option specified (default)
>>>>      - it tries to work as with the security option specified
>>>>      - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
>>>>      - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
>>>>      - and keep vt-d enabled
>>>>
>>>>         
>>> the default iommu=1 works like iommu=force if BIOS is correct. But in 
>>>  fact we encountered some buggy BIOS, and then we added some 
>>> workarounds  to make VT-d still be enabled,  or warn and disable VT-d 
>>> if the issue is  regarded as invalid and cannot be workarounded. 
>>> These workarounds make  Xen more defensive to VT-d BIOS issues. The 
>>> panic only occurs when  operating VT-d hardware fails, because it 
>>> means the hardware is possibly  malfunctional.
>>>
>>> In short, default iommu=1 can workaround known VT-d BIOS issues we   
>>> observed till now, while iommu=force ensures best security provided 
>>> by VT-d.
>>>
>>>     
>>
>> So the default iommu=1 might be insecure? And iommu=force is always 
>> secure? 
>>
>> To me "force" sounds like it makes it work always, no matter if it's secure or not..
>>   
> The "security" here means the protection provided VT-d. The main  
> difference between them is iommu=force tries to enable all VT-d units in  
> any case, if any VT-d unit cannot enabled, it will quit Xen booting  
> (panic), thus it guarantees security provided by VT-d. while when  
> iommu=1, in order to workaround some BIOS issues, it will ignore some  
> invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d. 
>

Ok.. Thanks for explaining it. 

-- Pasi

Re: [PATCH] VT-d: improve RMRR validity checking

[Sander Eikelenboom]

Hmm perhaps somewhat unrelated, but is there a comprehensive list with Xen specific boot options with explanation ?

Since some seem to be valid for 2.6.18.8 some for pvops as well, and the hypervisor has some of her own.
If not I could perhaps try to make a Wiki with a table with options and explanation for it ?

This discussion seems to show sometimes you can interpret some option names in multiple ways and things have additional consequences.

--
Sander


Saturday, January 23, 2010, 2:08:50 PM, you wrote:

> On Sat, Jan 23, 2010 at 08:40:10PM +0800, Weidong Han wrote:
>> Pasi Kärkkäinen wrote:
>>> On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
>>>   
>>>> Sander Eikelenboom wrote:
>>>>     
>>>>> Hello Weidong,
>>>>>
>>>>> Wouldn't it be more clear to add an option to iommu= for this case ?
>>>>>
>>>>> if iommu=on,..,..,security
>>>>>
>>>>> With the security option specified:
>>>>>      -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
>>>>>      -warn,fail or panic incase it can't enable all to enforce the security.
>>>>>         
>>>> iommu=force is for security. It does as you described above. So I 
>>>> think  "security" option is not necessary.
>>>>     
>>>>> Without the security option specified (default)
>>>>>      - it tries to work as with the security option specified
>>>>>      - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
>>>>>      - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
>>>>>      - and keep vt-d enabled
>>>>>
>>>>>         
>>>> the default iommu=1 works like iommu=force if BIOS is correct. But in 
>>>>  fact we encountered some buggy BIOS, and then we added some 
>>>> workarounds  to make VT-d still be enabled,  or warn and disable VT-d 
>>>> if the issue is  regarded as invalid and cannot be workarounded. 
>>>> These workarounds make  Xen more defensive to VT-d BIOS issues. The 
>>>> panic only occurs when  operating VT-d hardware fails, because it 
>>>> means the hardware is possibly  malfunctional.
>>>>
>>>> In short, default iommu=1 can workaround known VT-d BIOS issues we   
>>>> observed till now, while iommu=force ensures best security provided 
>>>> by VT-d.
>>>>
>>>>     
>>>
>>> So the default iommu=1 might be insecure? And iommu=force is always 
>>> secure? 
>>>
>>> To me "force" sounds like it makes it work always, no matter if it's secure or not..
>>>   
>> The "security" here means the protection provided VT-d. The main  
>> difference between them is iommu=force tries to enable all VT-d units in  
>> any case, if any VT-d unit cannot enabled, it will quit Xen booting  
>> (panic), thus it guarantees security provided by VT-d. while when  
>> iommu=1, in order to workaround some BIOS issues, it will ignore some  
>> invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d. 
>>

> Ok.. Thanks for explaining it. 

> -- Pasi




-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options

[Pasi Kärkkäinen]

On Sat, Jan 23, 2010 at 03:33:50PM +0100, Sander Eikelenboom wrote:
> Hmm perhaps somewhat unrelated, but is there a comprehensive list with Xen specific boot options with explanation ?
> 
> Since some seem to be valid for 2.6.18.8 some for pvops as well, and the hypervisor has some of her own.
> If not I could perhaps try to make a Wiki with a table with options and explanation for it ?
> 
> This discussion seems to show sometimes you can interpret some option names in multiple ways and things have additional consequences.
> 

Have you checked this wiki page?:
http://wiki.xensource.com/xenwiki/VTdHowTo

But yeah, I think we should definitely add a wiki page
describing all the Xen + Dom0 kernel options.. a list that's up to date.

Stephen: Did you make some PDF document about Xen hypervisor boot options? 
I remember you doing PDF about the /etc/xen/<guest> cfgfile options earlier.

I think these documents should be put to a wiki page, it's much easier to update
and read them there.

-- Pasi


> --
> Sander
> 
> 
> Saturday, January 23, 2010, 2:08:50 PM, you wrote:
> 
> > On Sat, Jan 23, 2010 at 08:40:10PM +0800, Weidong Han wrote:
> >> Pasi Kärkkäinen wrote:
> >>> On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
> >>>   
> >>>> Sander Eikelenboom wrote:
> >>>>     
> >>>>> Hello Weidong,
> >>>>>
> >>>>> Wouldn't it be more clear to add an option to iommu= for this case ?
> >>>>>
> >>>>> if iommu=on,..,..,security
> >>>>>
> >>>>> With the security option specified:
> >>>>>      -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
> >>>>>      -warn,fail or panic incase it can't enable all to enforce the security.
> >>>>>         
> >>>> iommu=force is for security. It does as you described above. So I 
> >>>> think  "security" option is not necessary.
> >>>>     
> >>>>> Without the security option specified (default)
> >>>>>      - it tries to work as with the security option specified
> >>>>>      - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
> >>>>>      - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
> >>>>>      - and keep vt-d enabled
> >>>>>
> >>>>>         
> >>>> the default iommu=1 works like iommu=force if BIOS is correct. But in 
> >>>>  fact we encountered some buggy BIOS, and then we added some 
> >>>> workarounds  to make VT-d still be enabled,  or warn and disable VT-d 
> >>>> if the issue is  regarded as invalid and cannot be workarounded. 
> >>>> These workarounds make  Xen more defensive to VT-d BIOS issues. The 
> >>>> panic only occurs when  operating VT-d hardware fails, because it 
> >>>> means the hardware is possibly  malfunctional.
> >>>>
> >>>> In short, default iommu=1 can workaround known VT-d BIOS issues we   
> >>>> observed till now, while iommu=force ensures best security provided 
> >>>> by VT-d.
> >>>>
> >>>>     
> >>>
> >>> So the default iommu=1 might be insecure? And iommu=force is always 
> >>> secure? 
> >>>
> >>> To me "force" sounds like it makes it work always, no matter if it's secure or not..
> >>>   
> >> The "security" here means the protection provided VT-d. The main  
> >> difference between them is iommu=force tries to enable all VT-d units in  
> >> any case, if any VT-d unit cannot enabled, it will quit Xen booting  
> >> (panic), thus it guarantees security provided by VT-d. while when  
> >> iommu=1, in order to workaround some BIOS issues, it will ignore some  
> >> invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d. 
> >>
> 
> > Ok.. Thanks for explaining it. 
> 
> > -- Pasi
> 
> 
> 
> 
> -- 
> Best regards,
>  Sander                            mailto:linux@eikelenboom.it
> 

RE: [PATCH] VT-d: improve RMRR validity checking, documenting boot options

[Stephen Spector]

Team:

The document in question is located at http://www.xen.org/files/Support/XenConfigurationDetails.pdf. I am going to move the document into the Xen Wiki this morning and will have the final version at http://wiki.xensource.com/xenwiki/XenConfigurationFileOptions. Thanks.

...spector

-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
Sent: Saturday, January 23, 2010 9:55 AM
To: Sander Eikelenboom
Cc: Weidong Han; xen-devel@lists.xensource.com; Kay, Allen M; Cihula, Joseph; Noboru Iwamatsu; Keir Fraser; Stephen Spector
Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options

On Sat, Jan 23, 2010 at 03:33:50PM +0100, Sander Eikelenboom wrote:
> Hmm perhaps somewhat unrelated, but is there a comprehensive list with Xen specific boot options with explanation ?
> 
> Since some seem to be valid for 2.6.18.8 some for pvops as well, and the hypervisor has some of her own.
> If not I could perhaps try to make a Wiki with a table with options and explanation for it ?
> 
> This discussion seems to show sometimes you can interpret some option names in multiple ways and things have additional consequences.
> 

Have you checked this wiki page?:
http://wiki.xensource.com/xenwiki/VTdHowTo

But yeah, I think we should definitely add a wiki page
describing all the Xen + Dom0 kernel options.. a list that's up to date.

Stephen: Did you make some PDF document about Xen hypervisor boot options? 
I remember you doing PDF about the /etc/xen/<guest> cfgfile options earlier.

I think these documents should be put to a wiki page, it's much easier to update
and read them there.

-- Pasi


> --
> Sander
> 
> 
> Saturday, January 23, 2010, 2:08:50 PM, you wrote:
> 
> > On Sat, Jan 23, 2010 at 08:40:10PM +0800, Weidong Han wrote:
> >> Pasi Kärkkäinen wrote:
> >>> On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
> >>>   
> >>>> Sander Eikelenboom wrote:
> >>>>     
> >>>>> Hello Weidong,
> >>>>>
> >>>>> Wouldn't it be more clear to add an option to iommu= for this case ?
> >>>>>
> >>>>> if iommu=on,..,..,security
> >>>>>
> >>>>> With the security option specified:
> >>>>>      -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
> >>>>>      -warn,fail or panic incase it can't enable all to enforce the security.
> >>>>>         
> >>>> iommu=force is for security. It does as you described above. So I 
> >>>> think  "security" option is not necessary.
> >>>>     
> >>>>> Without the security option specified (default)
> >>>>>      - it tries to work as with the security option specified
> >>>>>      - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
> >>>>>      - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
> >>>>>      - and keep vt-d enabled
> >>>>>
> >>>>>         
> >>>> the default iommu=1 works like iommu=force if BIOS is correct. But in 
> >>>>  fact we encountered some buggy BIOS, and then we added some 
> >>>> workarounds  to make VT-d still be enabled,  or warn and disable VT-d 
> >>>> if the issue is  regarded as invalid and cannot be workarounded. 
> >>>> These workarounds make  Xen more defensive to VT-d BIOS issues. The 
> >>>> panic only occurs when  operating VT-d hardware fails, because it 
> >>>> means the hardware is possibly  malfunctional.
> >>>>
> >>>> In short, default iommu=1 can workaround known VT-d BIOS issues we   
> >>>> observed till now, while iommu=force ensures best security provided 
> >>>> by VT-d.
> >>>>
> >>>>     
> >>>
> >>> So the default iommu=1 might be insecure? And iommu=force is always 
> >>> secure? 
> >>>
> >>> To me "force" sounds like it makes it work always, no matter if it's secure or not..
> >>>   
> >> The "security" here means the protection provided VT-d. The main  
> >> difference between them is iommu=force tries to enable all VT-d units in  
> >> any case, if any VT-d unit cannot enabled, it will quit Xen booting  
> >> (panic), thus it guarantees security provided by VT-d. while when  
> >> iommu=1, in order to workaround some BIOS issues, it will ignore some  
> >> invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d. 
> >>
> 
> > Ok.. Thanks for explaining it. 
> 
> > -- Pasi
> 
> 
> 
> 
> -- 
> Best regards,
>  Sander                            mailto:linux@eikelenboom.it
> 

Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options)

[Sander Eikelenboom]

Hello Stephen,

Although I think this is an enrichment for the wiki docs, the pdf doesn't contain what i meant :-)
This pdf document gives (all) options to specify for xen guests.

What i was wondering about was all the options that i could:
- pass to the hypervisor on boot.
    - for example dom0_mem=xxx or serial console settings, iommu/vt-d options, xen powermanagement options, debug options like "cpufreq.debug=2" etc.

- as well as the xen-specific/related options one could give to the dom0 linux kernel (for both the 2.6.18.8 branch as well as jeremy's pvops).
    - for example console options that would work with serial console, pciback, reassign_resources, guestdev etc.

I don't know if you also have any starting document about this as well ?
Perhaps other wiki's about specific subjects could point to such a list for the latest and greatest in related boot options as well.

If there isn't such document i would like to help and try to contribute such a list.

--

Regards

Sander





Monday, January 25, 2010, 5:40:53 PM, you wrote:

> Team:

> The document in question is located at http://www.xen.org/files/Support/XenConfigurationDetails.pdf. I am going to move the document into the Xen Wiki this morning and will have the final version at http://wiki.xensource.com/xenwiki/XenConfigurationFileOptions. Thanks.

> ...spector

> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@iki.fi] 
> Sent: Saturday, January 23, 2010 9:55 AM
> To: Sander Eikelenboom
> Cc: Weidong Han; xen-devel@lists.xensource.com; Kay, Allen M; Cihula, Joseph; Noboru Iwamatsu; Keir Fraser; Stephen Spector
> Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options

> On Sat, Jan 23, 2010 at 03:33:50PM +0100, Sander Eikelenboom wrote:
>> Hmm perhaps somewhat unrelated, but is there a comprehensive list with Xen specific boot options with explanation ?
>> 
>> Since some seem to be valid for 2.6.18.8 some for pvops as well, and the hypervisor has some of her own.
>> If not I could perhaps try to make a Wiki with a table with options and explanation for it ?
>> 
>> This discussion seems to show sometimes you can interpret some option names in multiple ways and things have additional consequences.
>> 

> Have you checked this wiki page?:
> http://wiki.xensource.com/xenwiki/VTdHowTo

> But yeah, I think we should definitely add a wiki page
> describing all the Xen + Dom0 kernel options.. a list that's up to date.

> Stephen: Did you make some PDF document about Xen hypervisor boot options? 
> I remember you doing PDF about the /etc/xen/<guest> cfgfile options earlier.

> I think these documents should be put to a wiki page, it's much easier to update
> and read them there.

> -- Pasi


>> --
>> Sander
>> 
>> 
>> Saturday, January 23, 2010, 2:08:50 PM, you wrote:
>> 
>> > On Sat, Jan 23, 2010 at 08:40:10PM +0800, Weidong Han wrote:
>> >> Pasi Kärkkäinen wrote:
>> >>> On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
>> >>>   
>> >>>> Sander Eikelenboom wrote:
>> >>>>     
>> >>>>> Hello Weidong,
>> >>>>>
>> >>>>> Wouldn't it be more clear to add an option to iommu= for this case ?
>> >>>>>
>> >>>>> if iommu=on,..,..,security
>> >>>>>
>> >>>>> With the security option specified:
>> >>>>>      -it would be most strict in it's checks, since enforcing security with the iommu requires that as you have pointed out.
>> >>>>>      -warn,fail or panic incase it can't enable all to enforce the security.
>> >>>>>         
>> >>>> iommu=force is for security. It does as you described above. So I 
>> >>>> think  "security" option is not necessary.
>> >>>>     
>> >>>>> Without the security option specified (default)
>> >>>>>      - it tries to work as with the security option specified
>> >>>>>      - but incase of problems makes the assumption the iommu's main task is not security, but making as much of vt-d working to keep the passthrough functionality
>> >>>>>      - it will only warn, that you will lose the security part, that it would be wise to let your bios be fixed, and not making it panic
>> >>>>>      - and keep vt-d enabled
>> >>>>>
>> >>>>>         
>> >>>> the default iommu=1 works like iommu=force if BIOS is correct. But in 
>> >>>>  fact we encountered some buggy BIOS, and then we added some 
>> >>>> workarounds  to make VT-d still be enabled,  or warn and disable VT-d 
>> >>>> if the issue is  regarded as invalid and cannot be workarounded. 
>> >>>> These workarounds make  Xen more defensive to VT-d BIOS issues. The 
>> >>>> panic only occurs when  operating VT-d hardware fails, because it 
>> >>>> means the hardware is possibly  malfunctional.
>> >>>>
>> >>>> In short, default iommu=1 can workaround known VT-d BIOS issues we   
>> >>>> observed till now, while iommu=force ensures best security provided 
>> >>>> by VT-d.
>> >>>>
>> >>>>     
>> >>>
>> >>> So the default iommu=1 might be insecure? And iommu=force is always 
>> >>> secure? 
>> >>>
>> >>> To me "force" sounds like it makes it work always, no matter if it's secure or not..
>> >>>   
>> >> The "security" here means the protection provided VT-d. The main  
>> >> difference between them is iommu=force tries to enable all VT-d units in  
>> >> any case, if any VT-d unit cannot enabled, it will quit Xen booting  
>> >> (panic), thus it guarantees security provided by VT-d. while when  
>> >> iommu=1, in order to workaround some BIOS issues, it will ignore some  
>> >> invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d. 
>> >>
>> 
>> > Ok.. Thanks for explaining it. 
>> 
>> > -- Pasi
>> 
>> 
>> 
>> 
>> -- 
>> Best regards,
>>  Sander                            mailto:linux@eikelenboom.it
>> 



-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

RE: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options)

[Stephen Spector]

> Although I think this is an enrichment for the wiki docs, the pdf doesn't contain what i meant :-)
> This pdf document gives (all) options to specify for xen guests.

> What i was wondering about was all the options that i could:
> - pass to the hypervisor on boot.
>     - for example dom0_mem=xxx or serial console settings, iommu/vt-d options, xen powermanagement options, debug > options like "cpufreq.debug=2" etc.

> - as well as the xen-specific/related options one could give to the dom0 linux kernel (for both the 2.6.18.8 branch as > well as jeremy's pvops).
>     - for example console options that would work with serial console, pciback, reassign_resources, guestdev etc.

> I don't know if you also have any starting document about this as well ?
> Perhaps other wiki's about specific subjects could point to such a list for the latest and greatest in related boot > > > options as well.

> If there isn't such document i would like to help and try to contribute such a list.

I am not aware of any document that you mention but will wait to see if Jeremy Fitzhardinge has a comment on this.

Thanks.

...spector


 

Re: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options)

[Pasi Kärkkäinen]

On Mon, Jan 25, 2010 at 03:56:48PM -0500, Stephen Spector wrote:
> > Although I think this is an enrichment for the wiki docs, the pdf doesn't contain what i meant :-)
> > This pdf document gives (all) options to specify for xen guests.
> 
> > What i was wondering about was all the options that i could:
> > - pass to the hypervisor on boot.
> >     - for example dom0_mem=xxx or serial console settings, iommu/vt-d options, xen powermanagement options, debug > options like "cpufreq.debug=2" etc.
> 
> > - as well as the xen-specific/related options one could give to the dom0 linux kernel (for both the 2.6.18.8 branch as > well as jeremy's pvops).
> >     - for example console options that would work with serial console, pciback, reassign_resources, guestdev etc.
> 
> > I don't know if you also have any starting document about this as well ?
> > Perhaps other wiki's about specific subjects could point to such a list for the latest and greatest in related boot > > > options as well.
> 
> > If there isn't such document i would like to help and try to contribute such a list.
> 
> I am not aware of any document that you mention but will wait to see if Jeremy Fitzhardinge has a comment on this.
> 

I just made:
http://wiki.xensource.com/xenwiki/XenHypervisorBootOptions

Now we need to fill it with actual content.. Do we already 
have some more or less up-to-date PDF/txt/html file with
the Xen options? 

And I guess we should make a XenDom0KernelBootOptions 
wiki page aswell..

-- Pasi

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

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

Weidong,

I read the patch and the following thread.

I understood what you mean, but I think it's better to
limit the scope of "force_iommu".
And I believe RMRR should be checked as same as DRHD.

What I thought about DRHD is:
If all devices under the scope of the DRHD are non-existent,
this DRHD is invalid but safely ignorable, so ignore it.
If some devices under the scope of the DRHD are non-existent,
this DRHD is invalid, so disable VT-d unless "iommu=force"
option is specified.
When "iommu=force" option is specified, even the invalid DRHD
will be registered, because DRHD that has some existent devices
must not be ignored due to security reasons.

About the RMRR:
If all devices under the scope of the RMRR are non-existent,
this RMMR is invalid but ignorable, so ignore it.
If some devices under the scope of the RMRR are non-existent,
this RMRR is invalid, so disable VT-d unless "iommu=force"
option is specified. When "iommu=force" option is specified,
the invalid RMRR is ignored (it's safe).

I attach the patch.

What do you think?

Regards,
Noboru.

> I implemented a patch and attached.
>
> patch description:
> In order to make Xen more defensive to VT-d related BIOS issue, this
> patch ignores a DRHD if all devices under its scope are not pci
> discoverable, and regards a DRHD as invalid and then disable whole VT-d
> if some devices under its scope are not pci discoverable. But if
> iommu=force is set, it will enable all DRHDs reported by BIOS, to avoid
> any security vulnerability with malicious s/s re-enabling "supposed
> disabled" devices. Pls note that we don't know the devices under the
> "Include_all" DRHD are existent or not, because the scope of
> "Include_all" DRHD won't enumerate common pci device, it only enumerates
> I/OxAPIC and HPET devices.
>
> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
> Signed-off-by: Weidong Han <weidong.han@intel.com>
>
>
> Noboru, pls test the patch on your machine?
>
> Joe, could you review the patch? and pls ACK it if it's fine for you.
>
> Regards,
> Weidong
>
> Noboru Iwamatsu wrote:
>> Thanks,
>>
>> I understood.
>>
>>> Noboru Iwamatsu wrote:
>>>> Hi Weidong,
>>>>
>>>> I'm not sure why the security problem is caused by ignoring
>>>> the DRHD that has only non-existent devices.
>>>>
>>>> Could you explain details or where to read the spec?
>>> It's requested from security experts. The device that is not pci
>>> discoverable may be re-enabled by malicious software. If its DRHD is not
>>> enabled, the re-enabled device is not protected by VT-d. It will cause
>>> security issue.
>>>
>>>> As you saying, security is the top-priority.
>>>> However, when iommu=force is specified, we should enable vt-d
>>>> if there are some potential issues.
>>>> Because users want to "force" anyway.
>>> iommu=force was introduced to enable VT-d anyway for security purpose. I
>>> plan to still enable those DRHDs that includes non-existed device when
>>> iommu=force, otherwise ignore them.
>>>
>>> Regards,
>>> Weidong
>>>> Regards,
>>>> Noboru.
>>>>
>>>>> Keir Fraser wrote:
>>>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>>>> fail to
>>>>>> boot on a fairly wide range of modern systems. We have to
>>>>>> warn-and-disable,
>>>>>> partially or completely, unless iommu=force is specified. Or we
>>>>>> need to
>>>>>> revert to iommu=0 as the default.
>>>>>>
>>>>>> What do you think, Weidong?
>>>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>>>> security more when iommu=force. Therefore I will implement a patch
>>>>> based
>>>>> on Nororu's patch.
>>>>>
>>>>> Regards,
>>>>> Weidong
>>>>>
>>>>>> -- Keir
>>>>>>
>>>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello Weidong,
>>>>>>>
>>>>>>> The problem is most vendor's just don't fix it and ignore the
>>>>>>> problem
>>>>>>> completely.
>>>>>>> Most often hiding them selves behind: come back when it's a problem
>>>>>>> with
>>>>>>> Microsoft Windows, that the only single thing we support (and no
>>>>>>> other
>>>>>>> software, so no vmware, no xen, no linux, perhaps even no
>>>>>>> hypervisor)
>>>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>>>> now, but it
>>>>>>> didn't in the past as far as i know, so any complain bounces off,
>>>>>>> and
>>>>>>> there it
>>>>>>> all seems to end for them.
>>>>>>>
>>>>>>> Besides that i don't know if they do know what the problems with
>>>>>>> there
>>>>>>> implementation in BIOS is when someone reports it.
>>>>>>> I think some behind the scenes pressure from Intel to vendors might
>>>>>>> help to
>>>>>>> solve some of them.
>>>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>>>> that) also
>>>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>>>> switches off
>>>>>>> the IGD).
>>>>>>>
>>>>>>> Although i think in my case your patch will work around that for me.
>>>>>>> Perhaps a
>>>>>>> third option is needed, which does all the workarounds possible and
>>>>>>> warns
>>>>>>> about potential security problem when requested ?
>>>>>>>
>>>>>>> --
>>>>>>> Sander
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>>>
>>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>>> Hi Weidong,
>>>>>>>>>
>>>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>>>
>>>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>>>> invalid
>>>>>>>>> and not register.
>>>>>>>> Although you patch workarounds your buggy BIOS, but we still
>>>>>>>> need to
>>>>>>>> enable it for security purpose as I mentioned in previous mail. We
>>>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>>>> security
>>>>>>>> is more important for this specific BIOS issue. Did you report the
>>>>>>>> BIOS
>>>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in
>>>>>>>> BIOS.
>>>>>>>> Regards,
>>>>>>>> Weidong
>>>>>>>>> According to this patch and yours, my machine successfully booted
>>>>>>>>> with vt-d enabled.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>>>> I mean:
>>>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>>> looks reasonable.
>>>>>>>>>>>>
>>>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>>>> them to one
>>>>>>>>>>>> patch?
>>>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in
>>>>>>>>>>> one
>>>>>>>>>>> email.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Keir
>>>>>>>>>>>
>>>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the
>>>>>>>>>> RMRR
>>>>>>>>>> has
>>>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>>>> scope, we
>>>>>>>>>> should not ignore it because the existent devices under its scope
>>>>>>>>>> will
>>>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>>>> instead of
>>>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>
>>
>


[-- Attachment #2: drhd-rmrr-validation-fix.patch --]
[-- Type: text/plain, Size: 4881 bytes --]

diff -r ca0759a08057 -r 2b40508f7645 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Fri Jan 22 11:01:18 2010 +0000
+++ b/xen/drivers/passthrough/vtd/dmar.c	Mon Jan 25 15:36:32 2010 +0900
@@ -396,8 +396,65 @@
 
     if ( ret )
         xfree(dmaru);
+    else if ( dmaru->include_all )
+        acpi_register_drhd_unit(dmaru);
     else
-        acpi_register_drhd_unit(dmaru);
+    {
+        u8 b, d, f;
+        int i, invalid_cnt = 0;
+
+        for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
+        {
+            b = PCI_BUS(dmaru->scope.devices[i]);
+            d = PCI_SLOT(dmaru->scope.devices[i]);
+            f = PCI_FUNC(dmaru->scope.devices[i]);
+
+            if ( pci_device_detect(b, d, f) == 0 )
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  Non-existent device (%x:%x.%x) is reported "
+                    "in this DRHD's scope!\n", b, d, f);
+                invalid_cnt++;
+            }
+        }
+
+        /*
+         * If all devices under the scope of the DRHD are non-existent,
+         * this DRHD is invalid but safely ignorable, so ignore it.
+         * If some devices under the scope of the DRHD are non-existent,
+         * this DRHD is invalid, so disable VT-d unless "iommu=force"
+         * option is specified.
+         * When "iommu=force" option is specified, even the invalid DRHD
+         * will be registered, because DRHD that has some existent devices
+         * must not be ignored due to security reasons.
+         */
+        if ( invalid_cnt )
+        {
+            if ( invalid_cnt == dmaru->scope.devices_cnt )
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  Ignore the DRHD due to all devices under "
+                    "its scope are not PCI discoverable!\n");
+                xfree(dmaru);
+            }
+            else
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  The DRHD is invalid due to some devices under "
+                    "its scope are not PCI discoverable!\n");
+                if ( force_iommu )
+                    acpi_register_drhd_unit(dmaru);
+                else
+                {
+                    xfree(dmaru);
+                    ret = -EINVAL;
+                }
+            }
+        }
+        else
+            acpi_register_drhd_unit(dmaru);
+    }
+
     return ret;
 }
 
@@ -444,7 +501,7 @@
     else
     {
         u8 b, d, f;
-        int i, ignore = 0;
+        int i, invalid_cnt = 0;
 
         for ( i = 0; i < rmrru->scope.devices_cnt; i++ )
         {
@@ -458,24 +515,44 @@
                     "  Non-existent device (%x:%x.%x) is reported "
                     "in RMRR (%"PRIx64", %"PRIx64")'s scope!\n",
                     b, d, f, rmrru->base_address, rmrru->end_address);
-                ignore = 1;
+                invalid_cnt++;
+            }
+        }
+
+        /*
+         * If all devices under the scope of the RMRR are non-existent,
+         * this RMMR is invalid but ignorable, so ignore it.
+         * If some devices under the scope of the RMRR are non-existent,
+         * this RMRR is invalid, so disable VT-d unless "iommu=force"
+         * option is specified. When "iommu=force" option is specified,
+         * the invalid RMRR is ignored.
+         */
+        if ( invalid_cnt )
+        {
+            if ( invalid_cnt == rmrru->scope.devices_cnt )
+            {
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  Ignore the RMRR (%"PRIx64", %"PRIx64") due to "
+                    "devices under its scope are not PCI discoverable!\n",
+                    rmrru->base_address, rmrru->end_address);
+                xfree(rmrru);
+                return 0;
             }
             else
             {
-                ignore = 0;
-                break;
+                dprintk(XENLOG_WARNING VTDPREFIX,
+                    "  The RMRR (%"PRIx64", %"PRIx64") is invalid due to "
+                    "some devices under its scope are not PCI discoverable!\n",
+                    rmrru->base_address, rmrru->end_address);
+                if ( !force_iommu )
+                {
+                    xfree(rmrru);
+                    return -EINVAL;
+                }
             }
         }
 
-        if ( ignore )
-        {
-            dprintk(XENLOG_WARNING VTDPREFIX,
-                "  Ignore the RMRR (%"PRIx64", %"PRIx64") due to "
-                "devices under its scope are not PCI discoverable!\n",
-                rmrru->base_address, rmrru->end_address);
-            xfree(rmrru);
-        }
-        else if ( base_addr > end_addr )
+        if ( base_addr > end_addr )
         {
             dprintk(XENLOG_WARNING VTDPREFIX,
                 "  The RMRR (%"PRIx64", %"PRIx64") is incorrect!\n",

[-- 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] VT-d: improve RMRR validity checking

[Weidong Han]

Noboru Iwamatsu wrote:
> Weidong,
>
> I read the patch and the following thread.
>
> I understood what you mean, but I think it's better to
> limit the scope of "force_iommu".
> And I believe RMRR should be checked as same as DRHD.
>
> What I thought about DRHD is:
> If all devices under the scope of the DRHD are non-existent,
> this DRHD is invalid but safely ignorable, so ignore it.
>   
No, we cannot ignore it if iommu=force. The invisible device may be 
disabled, not really non-existent. it is possibly that it is re-enabled 
by malfunctional s/w. So when iommu=force, we should not ignore any 
DRHD. We ignores it just to workaround the BIOS issue you encountered.
> If some devices under the scope of the DRHD are non-existent,
> this DRHD is invalid, so disable VT-d unless "iommu=force"
> option is specified.
> When "iommu=force" option is specified, even the invalid DRHD
> will be registered, because DRHD that has some existent devices
> must not be ignored due to security reasons.
>
> About the RMRR:
> If all devices under the scope of the RMRR are non-existent,
> this RMMR is invalid but ignorable, so ignore it.
> If some devices under the scope of the RMRR are non-existent,
> this RMRR is invalid, so disable VT-d unless "iommu=force"
>   
RMRR is much different from DRHD, it's just reversed memories for 
specific devices (now only Intel IGD and USB contollers need RMRR), it's 
no security issue like described above.
    if "all" devices under the scope of the RMRR are non-existent, we 
can ignore the RMRR because no devices will use it.
    if  some" devices under the scope of the RMRR are non-existent, we 
cannot ignore the RMRR, because there are still some devices want to use 
it. I think we needn't to disable VT-d because it won't cause any 
issues. Of course, we also can disable VT-d for this case strictly.
> option is specified. When "iommu=force" option is specified,
> the invalid RMRR is ignored (it's safe).
>
>   
> I attach the patch.
>
> What do you think?
>   

Noboru,

I think it need not to change current code. BTW, your patch is not based 
on latest Xen.

Regards,
Weidong


> Regards,
> Noboru.
>
>   
>> I implemented a patch and attached.
>>
>> patch description:
>> In order to make Xen more defensive to VT-d related BIOS issue, this
>> patch ignores a DRHD if all devices under its scope are not pci
>> discoverable, and regards a DRHD as invalid and then disable whole VT-d
>> if some devices under its scope are not pci discoverable. But if
>> iommu=force is set, it will enable all DRHDs reported by BIOS, to avoid
>> any security vulnerability with malicious s/s re-enabling "supposed
>> disabled" devices. Pls note that we don't know the devices under the
>> "Include_all" DRHD are existent or not, because the scope of
>> "Include_all" DRHD won't enumerate common pci device, it only enumerates
>> I/OxAPIC and HPET devices.
>>
>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>
>>
>> Noboru, pls test the patch on your machine?
>>
>> Joe, could you review the patch? and pls ACK it if it's fine for you.
>>
>> Regards,
>> Weidong
>>
>> Noboru Iwamatsu wrote:
>>     
>>> Thanks,
>>>
>>> I understood.
>>>
>>>       
>>>> Noboru Iwamatsu wrote:
>>>>         
>>>>> Hi Weidong,
>>>>>
>>>>> I'm not sure why the security problem is caused by ignoring
>>>>> the DRHD that has only non-existent devices.
>>>>>
>>>>> Could you explain details or where to read the spec?
>>>>>           
>>>> It's requested from security experts. The device that is not pci
>>>> discoverable may be re-enabled by malicious software. If its DRHD is not
>>>> enabled, the re-enabled device is not protected by VT-d. It will cause
>>>> security issue.
>>>>
>>>>         
>>>>> As you saying, security is the top-priority.
>>>>> However, when iommu=force is specified, we should enable vt-d
>>>>> if there are some potential issues.
>>>>> Because users want to "force" anyway.
>>>>>           
>>>> iommu=force was introduced to enable VT-d anyway for security purpose. I
>>>> plan to still enable those DRHDs that includes non-existed device when
>>>> iommu=force, otherwise ignore them.
>>>>
>>>> Regards,
>>>> Weidong
>>>>         
>>>>> Regards,
>>>>> Noboru.
>>>>>
>>>>>           
>>>>>> Keir Fraser wrote:
>>>>>>             
>>>>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>>>>> fail to
>>>>>>> boot on a fairly wide range of modern systems. We have to
>>>>>>> warn-and-disable,
>>>>>>> partially or completely, unless iommu=force is specified. Or we
>>>>>>> need to
>>>>>>> revert to iommu=0 as the default.
>>>>>>>
>>>>>>> What do you think, Weidong?
>>>>>>>               
>>>>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>>>>> security more when iommu=force. Therefore I will implement a patch
>>>>>> based
>>>>>> on Nororu's patch.
>>>>>>
>>>>>> Regards,
>>>>>> Weidong
>>>>>>
>>>>>>             
>>>>>>> -- Keir
>>>>>>>
>>>>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it>
>>>>>>> wrote:
>>>>>>>
>>>>>>>               
>>>>>>>> Hello Weidong,
>>>>>>>>
>>>>>>>> The problem is most vendor's just don't fix it and ignore the
>>>>>>>> problem
>>>>>>>> completely.
>>>>>>>> Most often hiding them selves behind: come back when it's a problem
>>>>>>>> with
>>>>>>>> Microsoft Windows, that the only single thing we support (and no
>>>>>>>> other
>>>>>>>> software, so no vmware, no xen, no linux, perhaps even no
>>>>>>>> hypervisor)
>>>>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>>>>> now, but it
>>>>>>>> didn't in the past as far as i know, so any complain bounces off,
>>>>>>>> and
>>>>>>>> there it
>>>>>>>> all seems to end for them.
>>>>>>>>
>>>>>>>> Besides that i don't know if they do know what the problems with
>>>>>>>> there
>>>>>>>> implementation in BIOS is when someone reports it.
>>>>>>>> I think some behind the scenes pressure from Intel to vendors might
>>>>>>>> help to
>>>>>>>> solve some of them.
>>>>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>>>>> that) also
>>>>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>>>>> switches off
>>>>>>>> the IGD).
>>>>>>>>
>>>>>>>> Although i think in my case your patch will work around that for me.
>>>>>>>> Perhaps a
>>>>>>>> third option is needed, which does all the workarounds possible and
>>>>>>>> warns
>>>>>>>> about potential security problem when requested ?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sander
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>>>                   
>>>>>>>>>> Hi Weidong,
>>>>>>>>>>
>>>>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>>>>
>>>>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>>>>> invalid
>>>>>>>>>> and not register.
>>>>>>>>>>                     
>>>>>>>>> Although you patch workarounds your buggy BIOS, but we still
>>>>>>>>> need to
>>>>>>>>> enable it for security purpose as I mentioned in previous mail. We
>>>>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>>>>> security
>>>>>>>>> is more important for this specific BIOS issue. Did you report the
>>>>>>>>> BIOS
>>>>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in
>>>>>>>>> BIOS.
>>>>>>>>> Regards,
>>>>>>>>> Weidong
>>>>>>>>>                   
>>>>>>>>>> According to this patch and yours, my machine successfully booted
>>>>>>>>>> with vt-d enabled.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>>>                       
>>>>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>>>>> I mean:
>>>>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> looks reasonable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>>>>> them to one
>>>>>>>>>>>>> patch?
>>>>>>>>>>>>>                           
>>>>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in
>>>>>>>>>>>> one
>>>>>>>>>>>> email.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Keir
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the
>>>>>>>>>>> RMRR
>>>>>>>>>>> has
>>>>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>>>>> scope, we
>>>>>>>>>>> should not ignore it because the existent devices under its scope
>>>>>>>>>>> will
>>>>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>>>>> instead of
>>>>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>>>>>>>                       
>>>       
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Sander Eikelenboom]

Hello Weidong,

Is it possible to enable/disable DRHD's and RMRR's after boot ?

For example if one would hotplug a pci device, that wasn't existent on boot ..
What would happen considering security ?
Is it possible to enable DRHD for that device although it was non existent at boot ?

--
Sander



Monday, January 25, 2010, 8:56:24 AM, you wrote:

> Noboru Iwamatsu wrote:
>> Weidong,
>>
>> I read the patch and the following thread.
>>
>> I understood what you mean, but I think it's better to
>> limit the scope of "force_iommu".
>> And I believe RMRR should be checked as same as DRHD.
>>
>> What I thought about DRHD is:
>> If all devices under the scope of the DRHD are non-existent,
>> this DRHD is invalid but safely ignorable, so ignore it.
>>   
> No, we cannot ignore it if iommu=force. The invisible device may be 
> disabled, not really non-existent. it is possibly that it is re-enabled 
> by malfunctional s/w. So when iommu=force, we should not ignore any 
> DRHD. We ignores it just to workaround the BIOS issue you encountered.
>> If some devices under the scope of the DRHD are non-existent,
>> this DRHD is invalid, so disable VT-d unless "iommu=force"
>> option is specified.
>> When "iommu=force" option is specified, even the invalid DRHD
>> will be registered, because DRHD that has some existent devices
>> must not be ignored due to security reasons.
>>
>> About the RMRR:
>> If all devices under the scope of the RMRR are non-existent,
>> this RMMR is invalid but ignorable, so ignore it.
>> If some devices under the scope of the RMRR are non-existent,
>> this RMRR is invalid, so disable VT-d unless "iommu=force"
>>   
> RMRR is much different from DRHD, it's just reversed memories for 
> specific devices (now only Intel IGD and USB contollers need RMRR), it's 
> no security issue like described above.
>     if "all" devices under the scope of the RMRR are non-existent, we 
> can ignore the RMRR because no devices will use it.
>     if  some" devices under the scope of the RMRR are non-existent, we 
> cannot ignore the RMRR, because there are still some devices want to use 
> it. I think we needn't to disable VT-d because it won't cause any 
> issues. Of course, we also can disable VT-d for this case strictly.
>> option is specified. When "iommu=force" option is specified,
>> the invalid RMRR is ignored (it's safe).
>>
>>   
>> I attach the patch.
>>
>> What do you think?
>>   

> Noboru,

> I think it need not to change current code. BTW, your patch is not based 
> on latest Xen.

> Regards,
> Weidong


>> Regards,
>> Noboru.
>>
>>   
>>> I implemented a patch and attached.
>>>
>>> patch description:
>>> In order to make Xen more defensive to VT-d related BIOS issue, this
>>> patch ignores a DRHD if all devices under its scope are not pci
>>> discoverable, and regards a DRHD as invalid and then disable whole VT-d
>>> if some devices under its scope are not pci discoverable. But if
>>> iommu=force is set, it will enable all DRHDs reported by BIOS, to avoid
>>> any security vulnerability with malicious s/s re-enabling "supposed
>>> disabled" devices. Pls note that we don't know the devices under the
>>> "Include_all" DRHD are existent or not, because the scope of
>>> "Include_all" DRHD won't enumerate common pci device, it only enumerates
>>> I/OxAPIC and HPET devices.
>>>
>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>
>>>
>>> Noboru, pls test the patch on your machine?
>>>
>>> Joe, could you review the patch? and pls ACK it if it's fine for you.
>>>
>>> Regards,
>>> Weidong
>>>
>>> Noboru Iwamatsu wrote:
>>>     
>>>> Thanks,
>>>>
>>>> I understood.
>>>>
>>>>       
>>>>> Noboru Iwamatsu wrote:
>>>>>         
>>>>>> Hi Weidong,
>>>>>>
>>>>>> I'm not sure why the security problem is caused by ignoring
>>>>>> the DRHD that has only non-existent devices.
>>>>>>
>>>>>> Could you explain details or where to read the spec?
>>>>>>           
>>>>> It's requested from security experts. The device that is not pci
>>>>> discoverable may be re-enabled by malicious software. If its DRHD is not
>>>>> enabled, the re-enabled device is not protected by VT-d. It will cause
>>>>> security issue.
>>>>>
>>>>>         
>>>>>> As you saying, security is the top-priority.
>>>>>> However, when iommu=force is specified, we should enable vt-d
>>>>>> if there are some potential issues.
>>>>>> Because users want to "force" anyway.
>>>>>>           
>>>>> iommu=force was introduced to enable VT-d anyway for security purpose. I
>>>>> plan to still enable those DRHDs that includes non-existed device when
>>>>> iommu=force, otherwise ignore them.
>>>>>
>>>>> Regards,
>>>>> Weidong
>>>>>         
>>>>>> Regards,
>>>>>> Noboru.
>>>>>>
>>>>>>           
>>>>>>> Keir Fraser wrote:
>>>>>>>             
>>>>>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>>>>>> fail to
>>>>>>>> boot on a fairly wide range of modern systems. We have to
>>>>>>>> warn-and-disable,
>>>>>>>> partially or completely, unless iommu=force is specified. Or we
>>>>>>>> need to
>>>>>>>> revert to iommu=0 as the default.
>>>>>>>>
>>>>>>>> What do you think, Weidong?
>>>>>>>>               
>>>>>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>>>>>> security more when iommu=force. Therefore I will implement a patch
>>>>>>> based
>>>>>>> on Nororu's patch.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Weidong
>>>>>>>
>>>>>>>             
>>>>>>>> -- Keir
>>>>>>>>
>>>>>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>               
>>>>>>>>> Hello Weidong,
>>>>>>>>>
>>>>>>>>> The problem is most vendor's just don't fix it and ignore the
>>>>>>>>> problem
>>>>>>>>> completely.
>>>>>>>>> Most often hiding them selves behind: come back when it's a problem
>>>>>>>>> with
>>>>>>>>> Microsoft Windows, that the only single thing we support (and no
>>>>>>>>> other
>>>>>>>>> software, so no vmware, no xen, no linux, perhaps even no
>>>>>>>>> hypervisor)
>>>>>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>>>>>> now, but it
>>>>>>>>> didn't in the past as far as i know, so any complain bounces off,
>>>>>>>>> and
>>>>>>>>> there it
>>>>>>>>> all seems to end for them.
>>>>>>>>>
>>>>>>>>> Besides that i don't know if they do know what the problems with
>>>>>>>>> there
>>>>>>>>> implementation in BIOS is when someone reports it.
>>>>>>>>> I think some behind the scenes pressure from Intel to vendors might
>>>>>>>>> help to
>>>>>>>>> solve some of them.
>>>>>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>>>>>> that) also
>>>>>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>>>>>> switches off
>>>>>>>>> the IGD).
>>>>>>>>>
>>>>>>>>> Although i think in my case your patch will work around that for me.
>>>>>>>>> Perhaps a
>>>>>>>>> third option is needed, which does all the workarounds possible and
>>>>>>>>> warns
>>>>>>>>> about potential security problem when requested ?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sander
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>>>>>
>>>>>>>>>                 
>>>>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>>>>                   
>>>>>>>>>>> Hi Weidong,
>>>>>>>>>>>
>>>>>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>>>>>
>>>>>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>>>>>> invalid
>>>>>>>>>>> and not register.
>>>>>>>>>>>                     
>>>>>>>>>> Although you patch workarounds your buggy BIOS, but we still
>>>>>>>>>> need to
>>>>>>>>>> enable it for security purpose as I mentioned in previous mail. We
>>>>>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>>>>>> security
>>>>>>>>>> is more important for this specific BIOS issue. Did you report the
>>>>>>>>>> BIOS
>>>>>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in
>>>>>>>>>> BIOS.
>>>>>>>>>> Regards,
>>>>>>>>>> Weidong
>>>>>>>>>>                   
>>>>>>>>>>> According to this patch and yours, my machine successfully booted
>>>>>>>>>>> with vt-d enabled.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>>>>                       
>>>>>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>                         
>>>>>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>>>>>> I mean:
>>>>>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>> looks reasonable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>>>>>> them to one
>>>>>>>>>>>>>> patch?
>>>>>>>>>>>>>>                           
>>>>>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in
>>>>>>>>>>>>> one
>>>>>>>>>>>>> email.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Keir
>>>>>>>>>>>>>
>>>>>>>>>>>>>                         
>>>>>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the
>>>>>>>>>>>> RMRR
>>>>>>>>>>>> has
>>>>>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>>>>>> scope, we
>>>>>>>>>>>> should not ignore it because the existent devices under its scope
>>>>>>>>>>>> will
>>>>>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>>>>>> instead of
>>>>>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>>>>>>>>                       
>>>>       
>>
>>   




-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Sander Eikelenboom wrote:
> Hello Weidong,
>
> Is it possible to enable/disable DRHD's and RMRR's after boot ?
>
> For example if one would hotplug a pci device, that wasn't existent on boot ..
> What would happen considering security ?
> Is it possible to enable DRHD for that device although it was non existent at boot ?
>   

There is a "INCLUDE_ALL" DRHD, any hot added devices after boot will be 
handled by this DRHD. So it is no problem in hotplug case.

Regards,
Weidong
> --
> Sander
>
>
>
> Monday, January 25, 2010, 8:56:24 AM, you wrote:
>
>   
>> Noboru Iwamatsu wrote:
>>     
>>> Weidong,
>>>
>>> I read the patch and the following thread.
>>>
>>> I understood what you mean, but I think it's better to
>>> limit the scope of "force_iommu".
>>> And I believe RMRR should be checked as same as DRHD.
>>>
>>> What I thought about DRHD is:
>>> If all devices under the scope of the DRHD are non-existent,
>>> this DRHD is invalid but safely ignorable, so ignore it.
>>>   
>>>       
>> No, we cannot ignore it if iommu=force. The invisible device may be 
>> disabled, not really non-existent. it is possibly that it is re-enabled 
>> by malfunctional s/w. So when iommu=force, we should not ignore any 
>> DRHD. We ignores it just to workaround the BIOS issue you encountered.
>>     
>>> If some devices under the scope of the DRHD are non-existent,
>>> this DRHD is invalid, so disable VT-d unless "iommu=force"
>>> option is specified.
>>> When "iommu=force" option is specified, even the invalid DRHD
>>> will be registered, because DRHD that has some existent devices
>>> must not be ignored due to security reasons.
>>>
>>> About the RMRR:
>>> If all devices under the scope of the RMRR are non-existent,
>>> this RMMR is invalid but ignorable, so ignore it.
>>> If some devices under the scope of the RMRR are non-existent,
>>> this RMRR is invalid, so disable VT-d unless "iommu=force"
>>>   
>>>       
>> RMRR is much different from DRHD, it's just reversed memories for 
>> specific devices (now only Intel IGD and USB contollers need RMRR), it's 
>> no security issue like described above.
>>     if "all" devices under the scope of the RMRR are non-existent, we 
>> can ignore the RMRR because no devices will use it.
>>     if  some" devices under the scope of the RMRR are non-existent, we 
>> cannot ignore the RMRR, because there are still some devices want to use 
>> it. I think we needn't to disable VT-d because it won't cause any 
>> issues. Of course, we also can disable VT-d for this case strictly.
>>     
>>> option is specified. When "iommu=force" option is specified,
>>> the invalid RMRR is ignored (it's safe).
>>>
>>>   
>>> I attach the patch.
>>>
>>> What do you think?
>>>   
>>>       
>
>   
>> Noboru,
>>     
>
>   
>> I think it need not to change current code. BTW, your patch is not based 
>> on latest Xen.
>>     
>
>   
>> Regards,
>> Weidong
>>     
>
>
>   
>>> Regards,
>>> Noboru.
>>>
>>>   
>>>       
>>>> I implemented a patch and attached.
>>>>
>>>> patch description:
>>>> In order to make Xen more defensive to VT-d related BIOS issue, this
>>>> patch ignores a DRHD if all devices under its scope are not pci
>>>> discoverable, and regards a DRHD as invalid and then disable whole VT-d
>>>> if some devices under its scope are not pci discoverable. But if
>>>> iommu=force is set, it will enable all DRHDs reported by BIOS, to avoid
>>>> any security vulnerability with malicious s/s re-enabling "supposed
>>>> disabled" devices. Pls note that we don't know the devices under the
>>>> "Include_all" DRHD are existent or not, because the scope of
>>>> "Include_all" DRHD won't enumerate common pci device, it only enumerates
>>>> I/OxAPIC and HPET devices.
>>>>
>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>
>>>>
>>>> Noboru, pls test the patch on your machine?
>>>>
>>>> Joe, could you review the patch? and pls ACK it if it's fine for you.
>>>>
>>>> Regards,
>>>> Weidong
>>>>
>>>> Noboru Iwamatsu wrote:
>>>>     
>>>>         
>>>>> Thanks,
>>>>>
>>>>> I understood.
>>>>>
>>>>>       
>>>>>           
>>>>>> Noboru Iwamatsu wrote:
>>>>>>         
>>>>>>             
>>>>>>> Hi Weidong,
>>>>>>>
>>>>>>> I'm not sure why the security problem is caused by ignoring
>>>>>>> the DRHD that has only non-existent devices.
>>>>>>>
>>>>>>> Could you explain details or where to read the spec?
>>>>>>>           
>>>>>>>               
>>>>>> It's requested from security experts. The device that is not pci
>>>>>> discoverable may be re-enabled by malicious software. If its DRHD is not
>>>>>> enabled, the re-enabled device is not protected by VT-d. It will cause
>>>>>> security issue.
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> As you saying, security is the top-priority.
>>>>>>> However, when iommu=force is specified, we should enable vt-d
>>>>>>> if there are some potential issues.
>>>>>>> Because users want to "force" anyway.
>>>>>>>           
>>>>>>>               
>>>>>> iommu=force was introduced to enable VT-d anyway for security purpose. I
>>>>>> plan to still enable those DRHDs that includes non-existed device when
>>>>>> iommu=force, otherwise ignore them.
>>>>>>
>>>>>> Regards,
>>>>>> Weidong
>>>>>>         
>>>>>>             
>>>>>>> Regards,
>>>>>>> Noboru.
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>>>> Keir Fraser wrote:
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>>>>>>> fail to
>>>>>>>>> boot on a fairly wide range of modern systems. We have to
>>>>>>>>> warn-and-disable,
>>>>>>>>> partially or completely, unless iommu=force is specified. Or we
>>>>>>>>> need to
>>>>>>>>> revert to iommu=0 as the default.
>>>>>>>>>
>>>>>>>>> What do you think, Weidong?
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>>>>>>> security more when iommu=force. Therefore I will implement a patch
>>>>>>>> based
>>>>>>>> on Nororu's patch.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Weidong
>>>>>>>>
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> -- Keir
>>>>>>>>>
>>>>>>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> Hello Weidong,
>>>>>>>>>>
>>>>>>>>>> The problem is most vendor's just don't fix it and ignore the
>>>>>>>>>> problem
>>>>>>>>>> completely.
>>>>>>>>>> Most often hiding them selves behind: come back when it's a problem
>>>>>>>>>> with
>>>>>>>>>> Microsoft Windows, that the only single thing we support (and no
>>>>>>>>>> other
>>>>>>>>>> software, so no vmware, no xen, no linux, perhaps even no
>>>>>>>>>> hypervisor)
>>>>>>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>>>>>>> now, but it
>>>>>>>>>> didn't in the past as far as i know, so any complain bounces off,
>>>>>>>>>> and
>>>>>>>>>> there it
>>>>>>>>>> all seems to end for them.
>>>>>>>>>>
>>>>>>>>>> Besides that i don't know if they do know what the problems with
>>>>>>>>>> there
>>>>>>>>>> implementation in BIOS is when someone reports it.
>>>>>>>>>> I think some behind the scenes pressure from Intel to vendors might
>>>>>>>>>> help to
>>>>>>>>>> solve some of them.
>>>>>>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>>>>>>> that) also
>>>>>>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>>>>>>> switches off
>>>>>>>>>> the IGD).
>>>>>>>>>>
>>>>>>>>>> Although i think in my case your patch will work around that for me.
>>>>>>>>>> Perhaps a
>>>>>>>>>> third option is needed, which does all the workarounds possible and
>>>>>>>>>> warns
>>>>>>>>>> about potential security problem when requested ?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sander
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>>>>>>
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>>>> Hi Weidong,
>>>>>>>>>>>>
>>>>>>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>>>>>>
>>>>>>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>>>>>>> invalid
>>>>>>>>>>>> and not register.
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>> Although you patch workarounds your buggy BIOS, but we still
>>>>>>>>>>> need to
>>>>>>>>>>> enable it for security purpose as I mentioned in previous mail. We
>>>>>>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>>>>>>> security
>>>>>>>>>>> is more important for this specific BIOS issue. Did you report the
>>>>>>>>>>> BIOS
>>>>>>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in
>>>>>>>>>>> BIOS.
>>>>>>>>>>> Regards,
>>>>>>>>>>> Weidong
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>>>> According to this patch and yours, my machine successfully booted
>>>>>>>>>>>> with vt-d enabled.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                         
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>>>>>>> I mean:
>>>>>>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>>> looks reasonable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>>>>>>> them to one
>>>>>>>>>>>>>>> patch?
>>>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>> email.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Keir
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                         
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the
>>>>>>>>>>>>> RMRR
>>>>>>>>>>>>> has
>>>>>>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>>>>>>> scope, we
>>>>>>>>>>>>> should not ignore it because the existent devices under its scope
>>>>>>>>>>>>> will
>>>>>>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>>>>>>> instead of
>>>>>>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>>>>       
>>>>>           
>>>   
>>>       
>
>
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

Hi,

 > No, we cannot ignore it if iommu=force. The invisible device may be
 > disabled, not really non-existent. it is possibly that it is re-enabled
 > by malfunctional s/w. So when iommu=force, we should not ignore any
 > DRHD. We ignores it just to workaround the BIOS issue you encountered.

OK, I return to the same question as Pasi asked.
You mean even ignoring the DRHD that has no existent devices is
insecure, right?
In other word, iommu=1 might be insecure while working with workaround.

We might have to consider security and BIOS workaround separately.
I believe default action must be secure and enabled with strictly
checked values.
If "force" or some workaround options (e.g ignore_bogus_rmrr,
ignore_bogus_drhd, force_enable_with_bogus_drhd, ...)
specified, VT-d enabled with some special workaround, with
uncertain values, but these mode should be considered
"not always secure".

What do you think?

Regards,
Noboru.

> Noboru Iwamatsu wrote:
>> Weidong,
>>
>> I read the patch and the following thread.
>>
>> I understood what you mean, but I think it's better to
>> limit the scope of "force_iommu".
>> And I believe RMRR should be checked as same as DRHD.
>>
>> What I thought about DRHD is:
>> If all devices under the scope of the DRHD are non-existent,
>> this DRHD is invalid but safely ignorable, so ignore it.
> No, we cannot ignore it if iommu=force. The invisible device may be
> disabled, not really non-existent. it is possibly that it is re-enabled
> by malfunctional s/w. So when iommu=force, we should not ignore any
> DRHD. We ignores it just to workaround the BIOS issue you encountered.
>> If some devices under the scope of the DRHD are non-existent,
>> this DRHD is invalid, so disable VT-d unless "iommu=force"
>> option is specified.
>> When "iommu=force" option is specified, even the invalid DRHD
>> will be registered, because DRHD that has some existent devices
>> must not be ignored due to security reasons.
>>
>> About the RMRR:
>> If all devices under the scope of the RMRR are non-existent,
>> this RMMR is invalid but ignorable, so ignore it.
>> If some devices under the scope of the RMRR are non-existent,
>> this RMRR is invalid, so disable VT-d unless "iommu=force"
> RMRR is much different from DRHD, it's just reversed memories for
> specific devices (now only Intel IGD and USB contollers need RMRR), it's
> no security issue like described above.
> if "all" devices under the scope of the RMRR are non-existent, we can
> ignore the RMRR because no devices will use it.
> if some" devices under the scope of the RMRR are non-existent, we cannot
> ignore the RMRR, because there are still some devices want to use it. I
> think we needn't to disable VT-d because it won't cause any issues. Of
> course, we also can disable VT-d for this case strictly.
>> option is specified. When "iommu=force" option is specified,
>> the invalid RMRR is ignored (it's safe).
>>
>> I attach the patch.
>>
>> What do you think?
>
> Noboru,
>
> I think it need not to change current code. BTW, your patch is not based
> on latest Xen.
>
> Regards,
> Weidong
>
>
>> Regards,
>> Noboru.
>>
>>> I implemented a patch and attached.
>>>
>>> patch description:
>>> In order to make Xen more defensive to VT-d related BIOS issue, this
>>> patch ignores a DRHD if all devices under its scope are not pci
>>> discoverable, and regards a DRHD as invalid and then disable whole VT-d
>>> if some devices under its scope are not pci discoverable. But if
>>> iommu=force is set, it will enable all DRHDs reported by BIOS, to avoid
>>> any security vulnerability with malicious s/s re-enabling "supposed
>>> disabled" devices. Pls note that we don't know the devices under the
>>> "Include_all" DRHD are existent or not, because the scope of
>>> "Include_all" DRHD won't enumerate common pci device, it only enumerates
>>> I/OxAPIC and HPET devices.
>>>
>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>
>>>
>>> Noboru, pls test the patch on your machine?
>>>
>>> Joe, could you review the patch? and pls ACK it if it's fine for you.
>>>
>>> Regards,
>>> Weidong
>>>
>>> Noboru Iwamatsu wrote:
>>>> Thanks,
>>>>
>>>> I understood.
>>>>
>>>>> Noboru Iwamatsu wrote:
>>>>>> Hi Weidong,
>>>>>>
>>>>>> I'm not sure why the security problem is caused by ignoring
>>>>>> the DRHD that has only non-existent devices.
>>>>>>
>>>>>> Could you explain details or where to read the spec?
>>>>> It's requested from security experts. The device that is not pci
>>>>> discoverable may be re-enabled by malicious software. If its DRHD
>>>>> is not
>>>>> enabled, the re-enabled device is not protected by VT-d. It will cause
>>>>> security issue.
>>>>>
>>>>>> As you saying, security is the top-priority.
>>>>>> However, when iommu=force is specified, we should enable vt-d
>>>>>> if there are some potential issues.
>>>>>> Because users want to "force" anyway.
>>>>> iommu=force was introduced to enable VT-d anyway for security
>>>>> purpose. I
>>>>> plan to still enable those DRHDs that includes non-existed device when
>>>>> iommu=force, otherwise ignore them.
>>>>>
>>>>> Regards,
>>>>> Weidong
>>>>>> Regards,
>>>>>> Noboru.
>>>>>>
>>>>>>> Keir Fraser wrote:
>>>>>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>>>>>> fail to
>>>>>>>> boot on a fairly wide range of modern systems. We have to
>>>>>>>> warn-and-disable,
>>>>>>>> partially or completely, unless iommu=force is specified. Or we
>>>>>>>> need to
>>>>>>>> revert to iommu=0 as the default.
>>>>>>>>
>>>>>>>> What do you think, Weidong?
>>>>>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>>>>>> security more when iommu=force. Therefore I will implement a patch
>>>>>>> based
>>>>>>> on Nororu's patch.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Weidong
>>>>>>>
>>>>>>>> -- Keir
>>>>>>>>
>>>>>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hello Weidong,
>>>>>>>>>
>>>>>>>>> The problem is most vendor's just don't fix it and ignore the
>>>>>>>>> problem
>>>>>>>>> completely.
>>>>>>>>> Most often hiding them selves behind: come back when it's a
>>>>>>>>> problem
>>>>>>>>> with
>>>>>>>>> Microsoft Windows, that the only single thing we support (and no
>>>>>>>>> other
>>>>>>>>> software, so no vmware, no xen, no linux, perhaps even no
>>>>>>>>> hypervisor)
>>>>>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>>>>>> now, but it
>>>>>>>>> didn't in the past as far as i know, so any complain bounces off,
>>>>>>>>> and
>>>>>>>>> there it
>>>>>>>>> all seems to end for them.
>>>>>>>>>
>>>>>>>>> Besides that i don't know if they do know what the problems with
>>>>>>>>> there
>>>>>>>>> implementation in BIOS is when someone reports it.
>>>>>>>>> I think some behind the scenes pressure from Intel to vendors
>>>>>>>>> might
>>>>>>>>> help to
>>>>>>>>> solve some of them.
>>>>>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>>>>>> that) also
>>>>>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>>>>>> switches off
>>>>>>>>> the IGD).
>>>>>>>>>
>>>>>>>>> Although i think in my case your patch will work around that
>>>>>>>>> for me.
>>>>>>>>> Perhaps a
>>>>>>>>> third option is needed, which does all the workarounds possible
>>>>>>>>> and
>>>>>>>>> warns
>>>>>>>>> about potential security problem when requested ?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sander
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>>>>>
>>>>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>>>>> Hi Weidong,
>>>>>>>>>>>
>>>>>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>>>>>
>>>>>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>>>>>> invalid
>>>>>>>>>>> and not register.
>>>>>>>>>> Although you patch workarounds your buggy BIOS, but we still
>>>>>>>>>> need to
>>>>>>>>>> enable it for security purpose as I mentioned in previous
>>>>>>>>>> mail. We
>>>>>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>>>>>> security
>>>>>>>>>> is more important for this specific BIOS issue. Did you report
>>>>>>>>>> the
>>>>>>>>>> BIOS
>>>>>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in
>>>>>>>>>> BIOS.
>>>>>>>>>> Regards,
>>>>>>>>>> Weidong
>>>>>>>>>>> According to this patch and yours, my machine successfully
>>>>>>>>>>> booted
>>>>>>>>>>> with vt-d enabled.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>>>>>> I mean:
>>>>>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>>>>> looks reasonable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>>>>>> them to one
>>>>>>>>>>>>>> patch?
>>>>>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in
>>>>>>>>>>>>> one
>>>>>>>>>>>>> email.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Keir
>>>>>>>>>>>>>
>>>>>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the
>>>>>>>>>>>> RMRR
>>>>>>>>>>>> has
>>>>>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>>>>>> scope, we
>>>>>>>>>>>> should not ignore it because the existent devices under its
>>>>>>>>>>>> scope
>>>>>>>>>>>> will
>>>>>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>>>>>> instead of
>>>>>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>
>

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Noboru Iwamatsu wrote:
> Hi,
>
>  > No, we cannot ignore it if iommu=force. The invisible device may be
>  > disabled, not really non-existent. it is possibly that it is re-enabled
>  > by malfunctional s/w. So when iommu=force, we should not ignore any
>  > DRHD. We ignores it just to workaround the BIOS issue you encountered.
>
> OK, I return to the same question as Pasi asked.
> You mean even ignoring the DRHD that has no existent devices is
> insecure, right?
> In other word, iommu=1 might be insecure while working with workaround.
>   

Yes, from the VT-d point of view, there might be a device not protected 
by any DRHD if the device is re-enabled by malicious s/w and its DRHD is 
ignored.
> We might have to consider security and BIOS workaround separately.
> I believe default action must be secure and enabled with strictly
> checked values.
> If "force" or some workaround options (e.g ignore_bogus_rmrr,
> ignore_bogus_drhd, force_enable_with_bogus_drhd, ...)
> specified, VT-d enabled with some special workaround, with
> uncertain values, but these mode should be considered
> "not always secure".
>   
In order to still boot Xen, we will disable VT-d if detect some BIOS 
bugs, such as incorrect RMRR. iommu=force was introduced to enable VT-d 
anyway for security purpose, that means it won't allow to disable VT-d 
to boot Xen.  I agree to do the strict check for security by default, 
Maybe we can add an option like "workaround_bogus_bios" which will try 
to workaround known BIOS issues, such as ignore DRHD. I don't prefer to 
add too many options like ignore_bogus_rmrr and ignore_bogus_drhd, it's 
not practical for end users.

My suggestion is like:
iommu=1 (default): won't ignore any DRHD. when detect non-existent 
devices under DRHD's scope, and find incorrect RMRR setting, disable 
whole VT-d with warning message. This guarantees security when VT-d is 
enabled, or just disable VT-d to let Xen work without VT-d because there 
are users who don't need VT-d.
iommu=force: keep the same behavior. that's make sure VT-d enabled. It 
won't ignore any DRHD, and if VT-d is disabled due to above BIOS issues, 
it will quit Xen boot with warning message.
iommu=workaround_bogus_bios: if "all" devices under scope, ignore the 
DRHD, if "some" devices under scope, disable whole VT-d in Xen. This 
might be insecure because there might be a device not protected by any 
DRHD if the device is re-enabled by malicious s/w. This is for user who 
want to use VT-d regardless of security.

Welcome comments.

Regards,
Weidong
> What do you think?
>
> Regards,
> Noboru.
>
>   
>> Noboru Iwamatsu wrote:
>>     
>>> Weidong,
>>>
>>> I read the patch and the following thread.
>>>
>>> I understood what you mean, but I think it's better to
>>> limit the scope of "force_iommu".
>>> And I believe RMRR should be checked as same as DRHD.
>>>
>>> What I thought about DRHD is:
>>> If all devices under the scope of the DRHD are non-existent,
>>> this DRHD is invalid but safely ignorable, so ignore it.
>>>       
>> No, we cannot ignore it if iommu=force. The invisible device may be
>> disabled, not really non-existent. it is possibly that it is re-enabled
>> by malfunctional s/w. So when iommu=force, we should not ignore any
>> DRHD. We ignores it just to workaround the BIOS issue you encountered.
>>     
>>> If some devices under the scope of the DRHD are non-existent,
>>> this DRHD is invalid, so disable VT-d unless "iommu=force"
>>> option is specified.
>>> When "iommu=force" option is specified, even the invalid DRHD
>>> will be registered, because DRHD that has some existent devices
>>> must not be ignored due to security reasons.
>>>
>>> About the RMRR:
>>> If all devices under the scope of the RMRR are non-existent,
>>> this RMMR is invalid but ignorable, so ignore it.
>>> If some devices under the scope of the RMRR are non-existent,
>>> this RMRR is invalid, so disable VT-d unless "iommu=force"
>>>       
>> RMRR is much different from DRHD, it's just reversed memories for
>> specific devices (now only Intel IGD and USB contollers need RMRR), it's
>> no security issue like described above.
>> if "all" devices under the scope of the RMRR are non-existent, we can
>> ignore the RMRR because no devices will use it.
>> if some" devices under the scope of the RMRR are non-existent, we cannot
>> ignore the RMRR, because there are still some devices want to use it. I
>> think we needn't to disable VT-d because it won't cause any issues. Of
>> course, we also can disable VT-d for this case strictly.
>>     
>>> option is specified. When "iommu=force" option is specified,
>>> the invalid RMRR is ignored (it's safe).
>>>
>>> I attach the patch.
>>>
>>> What do you think?
>>>       
>> Noboru,
>>
>> I think it need not to change current code. BTW, your patch is not based
>> on latest Xen.
>>
>> Regards,
>> Weidong
>>
>>
>>     
>>> Regards,
>>> Noboru.
>>>
>>>       
>>>> I implemented a patch and attached.
>>>>
>>>> patch description:
>>>> In order to make Xen more defensive to VT-d related BIOS issue, this
>>>> patch ignores a DRHD if all devices under its scope are not pci
>>>> discoverable, and regards a DRHD as invalid and then disable whole VT-d
>>>> if some devices under its scope are not pci discoverable. But if
>>>> iommu=force is set, it will enable all DRHDs reported by BIOS, to avoid
>>>> any security vulnerability with malicious s/s re-enabling "supposed
>>>> disabled" devices. Pls note that we don't know the devices under the
>>>> "Include_all" DRHD are existent or not, because the scope of
>>>> "Include_all" DRHD won't enumerate common pci device, it only enumerates
>>>> I/OxAPIC and HPET devices.
>>>>
>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>
>>>>
>>>> Noboru, pls test the patch on your machine?
>>>>
>>>> Joe, could you review the patch? and pls ACK it if it's fine for you.
>>>>
>>>> Regards,
>>>> Weidong
>>>>
>>>> Noboru Iwamatsu wrote:
>>>>         
>>>>> Thanks,
>>>>>
>>>>> I understood.
>>>>>
>>>>>           
>>>>>> Noboru Iwamatsu wrote:
>>>>>>             
>>>>>>> Hi Weidong,
>>>>>>>
>>>>>>> I'm not sure why the security problem is caused by ignoring
>>>>>>> the DRHD that has only non-existent devices.
>>>>>>>
>>>>>>> Could you explain details or where to read the spec?
>>>>>>>               
>>>>>> It's requested from security experts. The device that is not pci
>>>>>> discoverable may be re-enabled by malicious software. If its DRHD
>>>>>> is not
>>>>>> enabled, the re-enabled device is not protected by VT-d. It will cause
>>>>>> security issue.
>>>>>>
>>>>>>             
>>>>>>> As you saying, security is the top-priority.
>>>>>>> However, when iommu=force is specified, we should enable vt-d
>>>>>>> if there are some potential issues.
>>>>>>> Because users want to "force" anyway.
>>>>>>>               
>>>>>> iommu=force was introduced to enable VT-d anyway for security
>>>>>> purpose. I
>>>>>> plan to still enable those DRHDs that includes non-existed device when
>>>>>> iommu=force, otherwise ignore them.
>>>>>>
>>>>>> Regards,
>>>>>> Weidong
>>>>>>             
>>>>>>> Regards,
>>>>>>> Noboru.
>>>>>>>
>>>>>>>               
>>>>>>>> Keir Fraser wrote:
>>>>>>>>                 
>>>>>>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>>>>>>> fail to
>>>>>>>>> boot on a fairly wide range of modern systems. We have to
>>>>>>>>> warn-and-disable,
>>>>>>>>> partially or completely, unless iommu=force is specified. Or we
>>>>>>>>> need to
>>>>>>>>> revert to iommu=0 as the default.
>>>>>>>>>
>>>>>>>>> What do you think, Weidong?
>>>>>>>>>                   
>>>>>>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>>>>>>> security more when iommu=force. Therefore I will implement a patch
>>>>>>>> based
>>>>>>>> on Nororu's patch.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Weidong
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> -- Keir
>>>>>>>>>
>>>>>>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> Hello Weidong,
>>>>>>>>>>
>>>>>>>>>> The problem is most vendor's just don't fix it and ignore the
>>>>>>>>>> problem
>>>>>>>>>> completely.
>>>>>>>>>> Most often hiding them selves behind: come back when it's a
>>>>>>>>>> problem
>>>>>>>>>> with
>>>>>>>>>> Microsoft Windows, that the only single thing we support (and no
>>>>>>>>>> other
>>>>>>>>>> software, so no vmware, no xen, no linux, perhaps even no
>>>>>>>>>> hypervisor)
>>>>>>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>>>>>>> now, but it
>>>>>>>>>> didn't in the past as far as i know, so any complain bounces off,
>>>>>>>>>> and
>>>>>>>>>> there it
>>>>>>>>>> all seems to end for them.
>>>>>>>>>>
>>>>>>>>>> Besides that i don't know if they do know what the problems with
>>>>>>>>>> there
>>>>>>>>>> implementation in BIOS is when someone reports it.
>>>>>>>>>> I think some behind the scenes pressure from Intel to vendors
>>>>>>>>>> might
>>>>>>>>>> help to
>>>>>>>>>> solve some of them.
>>>>>>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>>>>>>> that) also
>>>>>>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>>>>>>> switches off
>>>>>>>>>> the IGD).
>>>>>>>>>>
>>>>>>>>>> Although i think in my case your patch will work around that
>>>>>>>>>> for me.
>>>>>>>>>> Perhaps a
>>>>>>>>>> third option is needed, which does all the workarounds possible
>>>>>>>>>> and
>>>>>>>>>> warns
>>>>>>>>>> about potential security problem when requested ?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sander
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>>>>>                       
>>>>>>>>>>>> Hi Weidong,
>>>>>>>>>>>>
>>>>>>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>>>>>>
>>>>>>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>>>>>>> invalid
>>>>>>>>>>>> and not register.
>>>>>>>>>>>>                         
>>>>>>>>>>> Although you patch workarounds your buggy BIOS, but we still
>>>>>>>>>>> need to
>>>>>>>>>>> enable it for security purpose as I mentioned in previous
>>>>>>>>>>> mail. We
>>>>>>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>>>>>>> security
>>>>>>>>>>> is more important for this specific BIOS issue. Did you report
>>>>>>>>>>> the
>>>>>>>>>>> BIOS
>>>>>>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in
>>>>>>>>>>> BIOS.
>>>>>>>>>>> Regards,
>>>>>>>>>>> Weidong
>>>>>>>>>>>                       
>>>>>>>>>>>> According to this patch and yours, my machine successfully
>>>>>>>>>>>> booted
>>>>>>>>>>>> with vt-d enabled.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                         
>>>>>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>>>>>>> I mean:
>>>>>>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>>> looks reasonable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>>>>>>> them to one
>>>>>>>>>>>>>>> patch?
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>> email.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Keir
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the
>>>>>>>>>>>>> RMRR
>>>>>>>>>>>>> has
>>>>>>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>>>>>>> scope, we
>>>>>>>>>>>>> should not ignore it because the existent devices under its
>>>>>>>>>>>>> scope
>>>>>>>>>>>>> will
>>>>>>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>>>>>>> instead of
>>>>>>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>>>>>>>>>                           
>
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Sander Eikelenboom]

Hello Weidong,

vt-d can have 2 goals:
     1 security
     2 passthrough

a) I think (1) should be default for xen, but it requires that there are no bios problems with at least DRHD, RMRR could perhaps be worked around if i understand correctly.
     - When (1) security works, (2) passthrough will also work.
     - When this fails there are 2 ways to fail:
            - warn about problem and disable vt-d completely (your default with iommu=1)
            - panic (your option iommu=force)

b) If there are problems with DRHD (and/or RMRR) security isn't a goal that can be met anymore, so only (2) passthrough remains.
     - provide an option to workaround bios options (your option iommu=workaround_bogus_bios).


Comments:

a) Could be discussed if panic should be default instead of disabling iommu or not, although there seem to be a lot of broken bioses, so that would lead to a lot of machines not booting.

b) I think it would be best for the option "iommu=workaround_bogus_bios" to do a really best effort, and try to get as much of vt-d working to support passthrough (full security can't be met anyway, so shouldn't be a requirement anymore),
   and let auto disabling the whole iommu be the very very last resort. And also give a good warning/info about the insecurity and what exactly is wrong if possible, to report to vendors.


-- 

Sander






Monday, January 25, 2010, 11:08:15 AM, you wrote:

> Noboru Iwamatsu wrote:
>> Hi,
>>
>>  > No, we cannot ignore it if iommu=force. The invisible device may be
>>  > disabled, not really non-existent. it is possibly that it is re-enabled
>>  > by malfunctional s/w. So when iommu=force, we should not ignore any
>>  > DRHD. We ignores it just to workaround the BIOS issue you encountered.
>>
>> OK, I return to the same question as Pasi asked.
>> You mean even ignoring the DRHD that has no existent devices is
>> insecure, right?
>> In other word, iommu=1 might be insecure while working with workaround.
>>   

> Yes, from the VT-d point of view, there might be a device not protected 
> by any DRHD if the device is re-enabled by malicious s/w and its DRHD is 
> ignored.
>> We might have to consider security and BIOS workaround separately.
>> I believe default action must be secure and enabled with strictly
>> checked values.
>> If "force" or some workaround options (e.g ignore_bogus_rmrr,
>> ignore_bogus_drhd, force_enable_with_bogus_drhd, ...)
>> specified, VT-d enabled with some special workaround, with
>> uncertain values, but these mode should be considered
>> "not always secure".
>>   
> In order to still boot Xen, we will disable VT-d if detect some BIOS 
> bugs, such as incorrect RMRR. iommu=force was introduced to enable VT-d 
> anyway for security purpose, that means it won't allow to disable VT-d 
> to boot Xen.  I agree to do the strict check for security by default, 
> Maybe we can add an option like "workaround_bogus_bios" which will try 
> to workaround known BIOS issues, such as ignore DRHD. I don't prefer to 
> add too many options like ignore_bogus_rmrr and ignore_bogus_drhd, it's 
> not practical for end users.

> My suggestion is like:
> iommu=1 (default): won't ignore any DRHD. when detect non-existent 
> devices under DRHD's scope, and find incorrect RMRR setting, disable 
> whole VT-d with warning message. This guarantees security when VT-d is 
> enabled, or just disable VT-d to let Xen work without VT-d because there 
> are users who don't need VT-d.
> iommu=force: keep the same behavior. that's make sure VT-d enabled. It 
> won't ignore any DRHD, and if VT-d is disabled due to above BIOS issues, 
> it will quit Xen boot with warning message.
> iommu=workaround_bogus_bios: if "all" devices under scope, ignore the 
> DRHD, if "some" devices under scope, disable whole VT-d in Xen. This 
> might be insecure because there might be a device not protected by any 
> DRHD if the device is re-enabled by malicious s/w. This is for user who 
> want to use VT-d regardless of security.

> Welcome comments.

> Regards,
> Weidong
>> What do you think?
>>
>> Regards,
>> Noboru.
>>
>>   
>>> Noboru Iwamatsu wrote:
>>>     
>>>> Weidong,
>>>>
>>>> I read the patch and the following thread.
>>>>
>>>> I understood what you mean, but I think it's better to
>>>> limit the scope of "force_iommu".
>>>> And I believe RMRR should be checked as same as DRHD.
>>>>
>>>> What I thought about DRHD is:
>>>> If all devices under the scope of the DRHD are non-existent,
>>>> this DRHD is invalid but safely ignorable, so ignore it.
>>>>       
>>> No, we cannot ignore it if iommu=force. The invisible device may be
>>> disabled, not really non-existent. it is possibly that it is re-enabled
>>> by malfunctional s/w. So when iommu=force, we should not ignore any
>>> DRHD. We ignores it just to workaround the BIOS issue you encountered.
>>>     
>>>> If some devices under the scope of the DRHD are non-existent,
>>>> this DRHD is invalid, so disable VT-d unless "iommu=force"
>>>> option is specified.
>>>> When "iommu=force" option is specified, even the invalid DRHD
>>>> will be registered, because DRHD that has some existent devices
>>>> must not be ignored due to security reasons.
>>>>
>>>> About the RMRR:
>>>> If all devices under the scope of the RMRR are non-existent,
>>>> this RMMR is invalid but ignorable, so ignore it.
>>>> If some devices under the scope of the RMRR are non-existent,
>>>> this RMRR is invalid, so disable VT-d unless "iommu=force"
>>>>       
>>> RMRR is much different from DRHD, it's just reversed memories for
>>> specific devices (now only Intel IGD and USB contollers need RMRR), it's
>>> no security issue like described above.
>>> if "all" devices under the scope of the RMRR are non-existent, we can
>>> ignore the RMRR because no devices will use it.
>>> if some" devices under the scope of the RMRR are non-existent, we cannot
>>> ignore the RMRR, because there are still some devices want to use it. I
>>> think we needn't to disable VT-d because it won't cause any issues. Of
>>> course, we also can disable VT-d for this case strictly.
>>>     
>>>> option is specified. When "iommu=force" option is specified,
>>>> the invalid RMRR is ignored (it's safe).
>>>>
>>>> I attach the patch.
>>>>
>>>> What do you think?
>>>>       
>>> Noboru,
>>>
>>> I think it need not to change current code. BTW, your patch is not based
>>> on latest Xen.
>>>
>>> Regards,
>>> Weidong
>>>
>>>
>>>     
>>>> Regards,
>>>> Noboru.
>>>>
>>>>       
>>>>> I implemented a patch and attached.
>>>>>
>>>>> patch description:
>>>>> In order to make Xen more defensive to VT-d related BIOS issue, this
>>>>> patch ignores a DRHD if all devices under its scope are not pci
>>>>> discoverable, and regards a DRHD as invalid and then disable whole VT-d
>>>>> if some devices under its scope are not pci discoverable. But if
>>>>> iommu=force is set, it will enable all DRHDs reported by BIOS, to avoid
>>>>> any security vulnerability with malicious s/s re-enabling "supposed
>>>>> disabled" devices. Pls note that we don't know the devices under the
>>>>> "Include_all" DRHD are existent or not, because the scope of
>>>>> "Include_all" DRHD won't enumerate common pci device, it only enumerates
>>>>> I/OxAPIC and HPET devices.
>>>>>
>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>
>>>>>
>>>>> Noboru, pls test the patch on your machine?
>>>>>
>>>>> Joe, could you review the patch? and pls ACK it if it's fine for you.
>>>>>
>>>>> Regards,
>>>>> Weidong
>>>>>
>>>>> Noboru Iwamatsu wrote:
>>>>>         
>>>>>> Thanks,
>>>>>>
>>>>>> I understood.
>>>>>>
>>>>>>           
>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>             
>>>>>>>> Hi Weidong,
>>>>>>>>
>>>>>>>> I'm not sure why the security problem is caused by ignoring
>>>>>>>> the DRHD that has only non-existent devices.
>>>>>>>>
>>>>>>>> Could you explain details or where to read the spec?
>>>>>>>>               
>>>>>>> It's requested from security experts. The device that is not pci
>>>>>>> discoverable may be re-enabled by malicious software. If its DRHD
>>>>>>> is not
>>>>>>> enabled, the re-enabled device is not protected by VT-d. It will cause
>>>>>>> security issue.
>>>>>>>
>>>>>>>             
>>>>>>>> As you saying, security is the top-priority.
>>>>>>>> However, when iommu=force is specified, we should enable vt-d
>>>>>>>> if there are some potential issues.
>>>>>>>> Because users want to "force" anyway.
>>>>>>>>               
>>>>>>> iommu=force was introduced to enable VT-d anyway for security
>>>>>>> purpose. I
>>>>>>> plan to still enable those DRHDs that includes non-existed device when
>>>>>>> iommu=force, otherwise ignore them.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Weidong
>>>>>>>             
>>>>>>>> Regards,
>>>>>>>> Noboru.
>>>>>>>>
>>>>>>>>               
>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>                 
>>>>>>>>>> If we want to keep iommu=1 as default, then it is unacceptable to
>>>>>>>>>> fail to
>>>>>>>>>> boot on a fairly wide range of modern systems. We have to
>>>>>>>>>> warn-and-disable,
>>>>>>>>>> partially or completely, unless iommu=force is specified. Or we
>>>>>>>>>> need to
>>>>>>>>>> revert to iommu=0 as the default.
>>>>>>>>>>
>>>>>>>>>> What do you think, Weidong?
>>>>>>>>>>                   
>>>>>>>>> Yes. I agree to warn-and-disable for these BIOS issues, and consider
>>>>>>>>> security more when iommu=force. Therefore I will implement a patch
>>>>>>>>> based
>>>>>>>>> on Nororu's patch.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Weidong
>>>>>>>>>
>>>>>>>>>                 
>>>>>>>>>> -- Keir
>>>>>>>>>>
>>>>>>>>>> On 21/01/2010 14:17, "Sander Eikelenboom" <linux@eikelenboom.it>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>                   
>>>>>>>>>>> Hello Weidong,
>>>>>>>>>>>
>>>>>>>>>>> The problem is most vendor's just don't fix it and ignore the
>>>>>>>>>>> problem
>>>>>>>>>>> completely.
>>>>>>>>>>> Most often hiding them selves behind: come back when it's a
>>>>>>>>>>> problem
>>>>>>>>>>> with
>>>>>>>>>>> Microsoft Windows, that the only single thing we support (and no
>>>>>>>>>>> other
>>>>>>>>>>> software, so no vmware, no xen, no linux, perhaps even no
>>>>>>>>>>> hypervisor)
>>>>>>>>>>> Well I don't know if the virtual pc in windows 7 supports an iommu
>>>>>>>>>>> now, but it
>>>>>>>>>>> didn't in the past as far as i know, so any complain bounces off,
>>>>>>>>>>> and
>>>>>>>>>>> there it
>>>>>>>>>>> all seems to end for them.
>>>>>>>>>>>
>>>>>>>>>>> Besides that i don't know if they do know what the problems with
>>>>>>>>>>> there
>>>>>>>>>>> implementation in BIOS is when someone reports it.
>>>>>>>>>>> I think some behind the scenes pressure from Intel to vendors
>>>>>>>>>>> might
>>>>>>>>>>> help to
>>>>>>>>>>> solve some of them.
>>>>>>>>>>> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for
>>>>>>>>>>> that) also
>>>>>>>>>>> suffers RMRR problem when another graphics card is inserted which
>>>>>>>>>>> switches off
>>>>>>>>>>> the IGD).
>>>>>>>>>>>
>>>>>>>>>>> Although i think in my case your patch will work around that
>>>>>>>>>>> for me.
>>>>>>>>>>> Perhaps a
>>>>>>>>>>> third option is needed, which does all the workarounds possible
>>>>>>>>>>> and
>>>>>>>>>>> warns
>>>>>>>>>>> about potential security problem when requested ?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sander
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>>>>>>>>> Noboru Iwamatsu wrote:
>>>>>>>>>>>>                       
>>>>>>>>>>>>> Hi Weidong,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I re-send the DRHD-fix patch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If DRHD does not have existent devices, ignore it.
>>>>>>>>>>>>> If DRHD has both existent and non-existent devices, consider it
>>>>>>>>>>>>> invalid
>>>>>>>>>>>>> and not register.
>>>>>>>>>>>>>                         
>>>>>>>>>>>> Although you patch workarounds your buggy BIOS, but we still
>>>>>>>>>>>> need to
>>>>>>>>>>>> enable it for security purpose as I mentioned in previous
>>>>>>>>>>>> mail. We
>>>>>>>>>>>> needn't workaround / fix all BIOS issues in software. I think
>>>>>>>>>>>> security
>>>>>>>>>>>> is more important for this specific BIOS issue. Did you report
>>>>>>>>>>>> the
>>>>>>>>>>>> BIOS
>>>>>>>>>>>> issue to your OEM vendor? maybe it's better to get it fixed in
>>>>>>>>>>>> BIOS.
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Weidong
>>>>>>>>>>>>                       
>>>>>>>>>>>>> According to this patch and yours, my machine successfully
>>>>>>>>>>>>> booted
>>>>>>>>>>>>> with vt-d enabled.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                         
>>>>>>>>>>>>>> Keir Fraser wrote:
>>>>>>>>>>>>>>                           
>>>>>>>>>>>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>>>> Sorry this is typo.
>>>>>>>>>>>>>>>>> I mean:
>>>>>>>>>>>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>>>>>>>>>>>> and whole RMRR should be ignored.
>>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>>>> looks reasonable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge
>>>>>>>>>>>>>>>> them to one
>>>>>>>>>>>>>>>> patch?
>>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>> Merge them up, re-send with both sign-off and acked-by all in
>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>> email.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Keir
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>> Sorry, I disagree with Noboru after thinking it again. If the
>>>>>>>>>>>>>> RMRR
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>> both no-existent device and also has existent devices in its
>>>>>>>>>>>>>> scope, we
>>>>>>>>>>>>>> should not ignore it because the existent devices under its
>>>>>>>>>>>>>> scope
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be impacted without the RMRR. so I suggest to print a warning
>>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>> ignore it. Attached a patch for it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>>>>>>>>>>>                           
>>
>>
>>
>>   






-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

Re: [PATCH] VT-d: improve RMRR validity checking

[Keir Fraser]

On 25/01/2010 10:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

> a) Could be discussed if panic should be default instead of disabling iommu or
> not, although there seem to be a lot of broken bioses, so that would lead to a
> lot of machines not booting.

Absolutely not acceptable. Warn and completely disable IOMMU is the correct
default causing least pain to the most end users.

 -- Keir

Re: [PATCH] VT-d: improve RMRR validity checking

[Christian Tramnitz]

How about a new config option "vtd=enforce" (if you think of selinux you 
know where that comes from) for the most secure "panic on deviations" to 
keep "force" working even with buggy BIOSes (which seem to be the 
majority right now) and to avoid problems for folks currently using 
"force" with something else in mind rather than their systems panicing 
after installing a broken BIOS...

I'd also love to see some initiative from Intel to actually make vendors 
offer proper BIOSes to support the technology they are advertising (and 
with advertising I do not mean vt-d specifically but advertising a 
chipset and at the same time Intel saying vt-d is supported on this 
chipset).


best regards,
    Christian

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Keir Fraser wrote:
> On 25/01/2010 10:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>
>   
>> a) Could be discussed if panic should be default instead of disabling iommu or
>> not, although there seem to be a lot of broken bioses, so that would lead to a
>> lot of machines not booting.
>>     
>
> Absolutely not acceptable. Warn and completely disable IOMMU is the correct
> default causing least pain to the most end users.
>
>  -- Keir
>
>   
Agree. It should not crash Xen by default due to BIOS issues. 
warn-and-disable is better. It won't impact common Xen users, and if a 
user really wants to use VT-d, he can try iommu=workaround_bogus_bios, 
or directly report to OEM vendor to get it fixed in BIOS. As VT-d is 
used more and more widely, I think the BIOS issues will be found and 
fixed more quickly than before, thus the situation should be better.

Regards,
Weidong

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

Weidong, Keir,

I agree your suggestions.

Noboru.

> Keir Fraser wrote:
>> On 25/01/2010 10:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>
>>> a) Could be discussed if panic should be default instead of disabling
>>> iommu or
>>> not, although there seem to be a lot of broken bioses, so that would
>>> lead to a
>>> lot of machines not booting.
>>
>> Absolutely not acceptable. Warn and completely disable IOMMU is the
>> correct
>> default causing least pain to the most end users.
>>
>> -- Keir
>>
> Agree. It should not crash Xen by default due to BIOS issues.
> warn-and-disable is better. It won't impact common Xen users, and if a
> user really wants to use VT-d, he can try iommu=workaround_bogus_bios,
> or directly report to OEM vendor to get it fixed in BIOS. As VT-d is
> used more and more widely, I think the BIOS issues will be found and
> fixed more quickly than before, thus the situation should be better.
>
> Regards,
> Weidong
>
>
>

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

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

I implemented a patch for it. Noboru, pls have a try on your machine.
If you use default iommu=1, VT-d will be disabled with warning messages.
If you use iommu=workaround_bios_bug, it should enable VT-d and works 
for you.
If you use iommu=force, it panics.

patch title: VT-d: add "iommu=workaround_bios_bug" option
patch description:
    Add this option to workaround BIOS bugs. Currently it ignores DRHD 
if "all" devices under its scope are not pci discoverable. This 
workarounds a BIOS bug in some platforms to make VT-d work. But note 
that this option doesn't guarantee security, because it might ignore DRHD.
    So there are 3 options which handle BIOS bugs differently:
    iommu=1 (default): If detect non-existent device under a DRHD's 
scope, or find incorrect RMRR setting (base_address > end_address), 
disable VT-d completely in Xen with warning messages. This guarantees 
security when VT-d enabled, or just disable VT-d to let Xen work without 
VT-d.
    iommu=force: it enforces to enable VT-d in Xen. If VT-d cannot be 
enabled, it will crashes Xen. This is mainly for users who must need VT-d.
    iommu=workaround_bogus_bios: it workarounds some BIOS bugs to make 
VT-d still work.  This might be insecure because there might be a device 
not protected by any DRHD if the device is re-enabled by malicious s/w. 
This is for users who want to use VT-d regardless of security.

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

Regards,
Weidong

Noboru Iwamatsu wrote:
> Weidong, Keir,
>
> I agree your suggestions.
>
> Noboru.
>
>   
>> Keir Fraser wrote:
>>     
>>> On 25/01/2010 10:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>>
>>>       
>>>> a) Could be discussed if panic should be default instead of disabling
>>>> iommu or
>>>> not, although there seem to be a lot of broken bioses, so that would
>>>> lead to a
>>>> lot of machines not booting.
>>>>         
>>> Absolutely not acceptable. Warn and completely disable IOMMU is the
>>> correct
>>> default causing least pain to the most end users.
>>>
>>> -- Keir
>>>
>>>       
>> Agree. It should not crash Xen by default due to BIOS issues.
>> warn-and-disable is better. It won't impact common Xen users, and if a
>> user really wants to use VT-d, he can try iommu=workaround_bogus_bios,
>> or directly report to OEM vendor to get it fixed in BIOS. As VT-d is
>> used more and more widely, I think the BIOS issues will be found and
>> fixed more quickly than before, thus the situation should be better.
>>
>> Regards,
>> Weidong
>>
>>
>>
>>     
>
>
>   


[-- Attachment #2: workaround-bios.patch --]
[-- Type: text/plain, Size: 3218 bytes --]

diff -r 5dabbf2826c5 xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Mon Jan 25 09:58:53 2010 +0800
+++ b/xen/drivers/passthrough/iommu.c	Tue Jan 26 21:17:46 2010 +0800
@@ -30,6 +30,8 @@ static int iommu_populate_page_table(str
  *   pv                         Enable IOMMU for PV domains
  *   no-pv                      Disable IOMMU for PV domains (default)
  *   force|required             Don't boot unless IOMMU is enabled
+ *   workaround_bios_bug        Workaround some bios issue to still enable
+                                VT-d, don't guarantee security
  *   passthrough                Enable VT-d DMA passthrough (no DMA
  *                              translation for Dom0)
  *   no-snoop                   Disable VT-d Snoop Control
@@ -40,6 +42,7 @@ int iommu_enabled = 1;
 int iommu_enabled = 1;
 int iommu_pv_enabled;
 int force_iommu;
+int iommu_workaround_bios_bug;
 int iommu_passthrough;
 int iommu_snoop = 1;
 int iommu_qinval = 1;
@@ -65,6 +68,8 @@ static void __init parse_iommu_param(cha
             iommu_pv_enabled = 0;
         else if ( !strcmp(s, "force") || !strcmp(s, "required") )
             force_iommu = 1;
+        else if ( !strcmp(s, "workaround_bios_bug") )
+            iommu_workaround_bios_bug = 1;
         else if ( !strcmp(s, "passthrough") )
             iommu_passthrough = 1;
         else if ( !strcmp(s, "no-snoop") )
diff -r 5dabbf2826c5 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Mon Jan 25 09:58:53 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c	Tue Jan 26 21:16:49 2010 +0800
@@ -421,17 +421,21 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
         if ( invalid_cnt )
         {
             xfree(dmaru);
-            if ( invalid_cnt == dmaru->scope.devices_cnt )
+
+            if ( iommu_workaround_bios_bug &&
+                 invalid_cnt == dmaru->scope.devices_cnt )
             {
                 dprintk(XENLOG_WARNING VTDPREFIX,
-                    "  Ignore the DRHD due to all devices under "
-                    "its scope are not PCI discoverable!\n");
+                    "  Workaround BIOS bug: ignore the DRHD due to all "
+                    "devices under its scope are not PCI discoverable!\n");
             }
             else
             {
                 dprintk(XENLOG_WARNING VTDPREFIX,
-                    "  The DRHD is invalid due to some devices under "
-                    "its scope are not PCI discoverable!\n");
+                    "  The DRHD is invalid due to there are devices under "
+                    "its scope are not PCI discoverable! Pls try option "
+                    "iommu=force or iommu=workaround_bios_bug if you "
+                    "really want VT-d\n");
                 ret = -EINVAL;
             }
         }
diff -r 5dabbf2826c5 xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Mon Jan 25 09:58:53 2010 +0800
+++ b/xen/include/xen/iommu.h	Tue Jan 26 21:17:08 2010 +0800
@@ -29,6 +29,7 @@ extern int iommu_enabled;
 extern int iommu_enabled;
 extern int iommu_pv_enabled;
 extern int force_iommu;
+extern int iommu_workaround_bios_bug;
 extern int iommu_passthrough;
 extern int iommu_snoop;
 extern int iommu_qinval;

[-- 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] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

Hi Weidong,

> I implemented a patch for it. Noboru, pls have a try on your machine.
> If you use default iommu=1, VT-d will be disabled with warning messages.
> If you use iommu=workaround_bios_bug, it should enable VT-d and works
> for you.
> If you use iommu=force, it panics.

On my machine, each options have worked as described.

I tried:
xen-unstable c/s 20844 + drhd-ignore.patch + workaround-bios.patch

Thanks,
Noboru.

> patch title: VT-d: add "iommu=workaround_bios_bug" option
> patch description:
> Add this option to workaround BIOS bugs. Currently it ignores DRHD if
> "all" devices under its scope are not pci discoverable. This workarounds
> a BIOS bug in some platforms to make VT-d work. But note that this
> option doesn't guarantee security, because it might ignore DRHD.
> So there are 3 options which handle BIOS bugs differently:
> iommu=1 (default): If detect non-existent device under a DRHD's scope,
> or find incorrect RMRR setting (base_address > end_address), disable
> VT-d completely in Xen with warning messages. This guarantees security
> when VT-d enabled, or just disable VT-d to let Xen work without VT-d.
> iommu=force: it enforces to enable VT-d in Xen. If VT-d cannot be
> enabled, it will crashes Xen. This is mainly for users who must need VT-d.
> iommu=workaround_bogus_bios: it workarounds some BIOS bugs to make VT-d
> still work. This might be insecure because there might be a device not
> protected by any DRHD if the device is re-enabled by malicious s/w. This
> is for users who want to use VT-d regardless of security.
>
> Signed-off-by: Weidong Han <weidong.han@intel.com>
>
> Regards,
> Weidong
>
> Noboru Iwamatsu wrote:
>> Weidong, Keir,
>>
>> I agree your suggestions.
>>
>> Noboru.
>>
>>> Keir Fraser wrote:
>>>> On 25/01/2010 10:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>>>
>>>>> a) Could be discussed if panic should be default instead of disabling
>>>>> iommu or
>>>>> not, although there seem to be a lot of broken bioses, so that would
>>>>> lead to a
>>>>> lot of machines not booting.
>>>> Absolutely not acceptable. Warn and completely disable IOMMU is the
>>>> correct
>>>> default causing least pain to the most end users.
>>>>
>>>> -- Keir
>>>>
>>> Agree. It should not crash Xen by default due to BIOS issues.
>>> warn-and-disable is better. It won't impact common Xen users, and if a
>>> user really wants to use VT-d, he can try iommu=workaround_bogus_bios,
>>> or directly report to OEM vendor to get it fixed in BIOS. As VT-d is
>>> used more and more widely, I think the BIOS issues will be found and
>>> fixed more quickly than before, thus the situation should be better.
>>>
>>> Regards,
>>> Weidong
>>>
>>>
>>>
>>
>>
>

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Noboru Iwamatsu wrote:
> Hi Weidong,
>
>   
>> I implemented a patch for it. Noboru, pls have a try on your machine.
>> If you use default iommu=1, VT-d will be disabled with warning messages.
>> If you use iommu=workaround_bios_bug, it should enable VT-d and works
>> for you.
>> If you use iommu=force, it panics.
>>     
>
> On my machine, each options have worked as described.
>   

Thanks Noboru.
> I tried:
> xen-unstable c/s 20844 + drhd-ignore.patch + workaround-bios.patch
>   
drhd-ignore.patch was already checked in as c/s 20846. Keir, pls check 
in the workaround-bios.patch. Thanks.

Regards,
Weidong
> Thanks,
> Noboru.
>
>   
>> patch title: VT-d: add "iommu=workaround_bios_bug" option
>> patch description:
>> Add this option to workaround BIOS bugs. Currently it ignores DRHD if
>> "all" devices under its scope are not pci discoverable. This workarounds
>> a BIOS bug in some platforms to make VT-d work. But note that this
>> option doesn't guarantee security, because it might ignore DRHD.
>> So there are 3 options which handle BIOS bugs differently:
>> iommu=1 (default): If detect non-existent device under a DRHD's scope,
>> or find incorrect RMRR setting (base_address > end_address), disable
>> VT-d completely in Xen with warning messages. This guarantees security
>> when VT-d enabled, or just disable VT-d to let Xen work without VT-d.
>> iommu=force: it enforces to enable VT-d in Xen. If VT-d cannot be
>> enabled, it will crashes Xen. This is mainly for users who must need VT-d.
>> iommu=workaround_bogus_bios: it workarounds some BIOS bugs to make VT-d
>> still work. This might be insecure because there might be a device not
>> protected by any DRHD if the device is re-enabled by malicious s/w. This
>> is for users who want to use VT-d regardless of security.
>>
>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>
>> Regards,
>> Weidong
>>
>> Noboru Iwamatsu wrote:
>>     
>>> Weidong, Keir,
>>>
>>> I agree your suggestions.
>>>
>>> Noboru.
>>>
>>>       
>>>> Keir Fraser wrote:
>>>>         
>>>>> On 25/01/2010 10:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>>>>
>>>>>           
>>>>>> a) Could be discussed if panic should be default instead of disabling
>>>>>> iommu or
>>>>>> not, although there seem to be a lot of broken bioses, so that would
>>>>>> lead to a
>>>>>> lot of machines not booting.
>>>>>>             
>>>>> Absolutely not acceptable. Warn and completely disable IOMMU is the
>>>>> correct
>>>>> default causing least pain to the most end users.
>>>>>
>>>>> -- Keir
>>>>>
>>>>>           
>>>> Agree. It should not crash Xen by default due to BIOS issues.
>>>> warn-and-disable is better. It won't impact common Xen users, and if a
>>>> user really wants to use VT-d, he can try iommu=workaround_bogus_bios,
>>>> or directly report to OEM vendor to get it fixed in BIOS. As VT-d is
>>>> used more and more widely, I think the BIOS issues will be found and
>>>> fixed more quickly than before, thus the situation should be better.
>>>>
>>>> Regards,
>>>> Weidong
>>>>
>>>>
>>>>
>>>>         
>>>       
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Keir Fraser wrote:
> On 25/01/2010 10:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>
>   
>> a) Could be discussed if panic should be default instead of disabling iommu or
>> not, although there seem to be a lot of broken bioses, so that would lead to a
>> lot of machines not booting.
>>     
>
> Absolutely not acceptable. Warn and completely disable IOMMU is the correct
> default causing least pain to the most end users.
>
>  -- Keir
>
>
>   
Agree. It should not crash Xen by default due to BIOS issues. 
warn-and-disable is better. It won't impact common Xen users, and if a 
user really wants to use VT-d, he can try iommu=workaround_bogus_bios, 
or directly report to OEM vendor to get it fixed in BIOS. As VT-d is 
used more and more widely, I think the BIOS issues will be found and 
fixed more quickly than before, thus the situation should be better.

Regards,
Weidong

RE: [PATCH] VT-d: improve RMRR validity checking

[Han, Weidong]

Agree. It should not crash Xen by default due to BIOS issues. warn-and-disable is better. It won't impact common Xen users, and if a user really wants to use VT-d, he can try iommu=workaround_bogus_bios, or directly report to OEM vendor to get it fixed in BIOS. As VT-d is used more and more widely, I think the BIOS issues will be found and fixed more quickly than before, thus the situation should be better.

Regards,
Weidong

-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] 
Sent: Monday, January 25, 2010 9:43 PM
To: Sander Eikelenboom; Han, Weidong
Cc: Noboru Iwamatsu; xen-devel@lists.xensource.com; Cihula, Joseph; Kay, Allen M
Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking

On 25/01/2010 10:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

> a) Could be discussed if panic should be default instead of disabling iommu or
> not, although there seem to be a lot of broken bioses, so that would lead to a
> lot of machines not booting.

Absolutely not acceptable. Warn and completely disable IOMMU is the correct
default causing least pain to the most end users.

 -- Keir

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Fri, Jan 22, 2010 at 1:47 AM, Weidong Han <weidong.han@intel.com> wrote:
> I implemented a patch and attached.
>
> patch description:
>   In order to make Xen more defensive to VT-d related BIOS issue, this patch
> ignores a DRHD if all devices under its scope are not pci discoverable, and
> regards a DRHD as invalid and then disable whole VT-d if some devices under
> its scope are not pci discoverable. But if iommu=force is set, it will
> enable all DRHDs reported by BIOS, to avoid any security vulnerability with
> malicious s/s re-enabling "supposed disabled" devices.  Pls note that we
> don't know the devices under the "Include_all" DRHD are existent or not,
> because the scope of "Include_all" DRHD  won't enumerate common pci device,
> it only enumerates I/OxAPIC and HPET devices.

Hi All,

I have a system with what I consider to be a valid DRHD that's getting
tripped up on this patch.  The problem is that the DRHD includes an
IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
think Xen is being overzealous in it's validity checking and that this
is a valid configuration.  What do others think?  Are IOAPICs a
special case that we can allow to be non-existent on the PCI bus?
Thanks,

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Konrad Rzeszutek Wilk]

On Tue, Mar 09, 2010 at 02:39:10PM -0700, Alex Williamson wrote:
> On Fri, Jan 22, 2010 at 1:47 AM, Weidong Han <weidong.han@intel.com> wrote:
> > I implemented a patch and attached.
> >
> > patch description:
> >   In order to make Xen more defensive to VT-d related BIOS issue, this patch
> > ignores a DRHD if all devices under its scope are not pci discoverable, and
> > regards a DRHD as invalid and then disable whole VT-d if some devices under
> > its scope are not pci discoverable. But if iommu=force is set, it will
> > enable all DRHDs reported by BIOS, to avoid any security vulnerability with
> > malicious s/s re-enabling "supposed disabled" devices.  Pls note that we
> > don't know the devices under the "Include_all" DRHD are existent or not,
> > because the scope of "Include_all" DRHD  won't enumerate common pci device,
> > it only enumerates I/OxAPIC and HPET devices.
> 
> Hi All,
> 
> I have a system with what I consider to be a valid DRHD that's getting
> tripped up on this patch.  The problem is that the DRHD includes an
> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
> think Xen is being overzealous in it's validity checking and that this
> is a valid configuration.  What do others think?  Are IOAPICs a

How does upstream Linux handle this?

> special case that we can allow to be non-existent on the PCI bus?
> Thanks,
> 
> Alex
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Tue, Mar 9, 2010 at 2:30 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Tue, Mar 09, 2010 at 02:39:10PM -0700, Alex Williamson wrote:
>>
>> I have a system with what I consider to be a valid DRHD that's getting
>> tripped up on this patch.  The problem is that the DRHD includes an
>> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
>> think Xen is being overzealous in it's validity checking and that this
>> is a valid configuration.  What do others think?  Are IOAPICs a
>
> How does upstream Linux handle this?

Last I checked, it works just fine, doesn't care that the IOAPIC isn't
materialized.

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Konrad Rzeszutek Wilk]

On Tue, Mar 09, 2010 at 02:57:00PM -0700, Alex Williamson wrote:
> On Tue, Mar 9, 2010 at 2:30 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Tue, Mar 09, 2010 at 02:39:10PM -0700, Alex Williamson wrote:
> >>
> >> I have a system with what I consider to be a valid DRHD that's getting
> >> tripped up on this patch.  The problem is that the DRHD includes an
> >> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
> >> think Xen is being overzealous in it's validity checking and that this
> >> is a valid configuration.  What do others think?  Are IOAPICs a
> >
> > How does upstream Linux handle this?
> 
> Last I checked, it works just fine, doesn't care that the IOAPIC isn't
> materialized.

This is from drivers/pci/intr_remapping.c (2.6.34-rc0):

795         if (ir_supported && ir_ioapic_num != nr_ioapics) {
796                 printk(KERN_WARNING
797                        "Not all IO-APIC's listed under remapping
hardware\n");
798                 return -1;
799         }
800 

ir_ioapic_num is figured out from the count of DRHD's.

So I think Linux would actually turn off VT-d.

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Tue, 2010-03-09 at 17:22 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 09, 2010 at 02:57:00PM -0700, Alex Williamson wrote:
> > On Tue, Mar 9, 2010 at 2:30 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > > On Tue, Mar 09, 2010 at 02:39:10PM -0700, Alex Williamson wrote:
> > >>
> > >> I have a system with what I consider to be a valid DRHD that's getting
> > >> tripped up on this patch.  The problem is that the DRHD includes an
> > >> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
> > >> think Xen is being overzealous in it's validity checking and that this
> > >> is a valid configuration.  What do others think?  Are IOAPICs a
> > >
> > > How does upstream Linux handle this?
> > 
> > Last I checked, it works just fine, doesn't care that the IOAPIC isn't
> > materialized.
> 
> This is from drivers/pci/intr_remapping.c (2.6.34-rc0):
> 
> 795         if (ir_supported && ir_ioapic_num != nr_ioapics) {
> 796                 printk(KERN_WARNING
> 797                        "Not all IO-APIC's listed under remapping
> hardware\n");
> 798                 return -1;
> 799         }
> 800 
> 
> ir_ioapic_num is figured out from the count of DRHD's.
> 
> So I think Linux would actually turn off VT-d.

In my case ir_ioapic_num will match nr_ioapics, so this shouldn't
disable on my system.

The problem with the current Xen code is that there's no requirement
that an IOAPIC is a PCI device, yet we have to describe it as a device
scope under a DRHD to enable interrupt remapping.  That means we have to
fill in the scope path with something, even if there's no device visible
there.  We happen to use the path of the IOAPIC if it were exposed so we
can keep straight what it is, but nothing requires it to be enumerable
on the PCI bus.  IMHO, the only important field in an IOAPIC DRHD scope
is the enumeration ID, which allows the OS/VMM to map the IOAPIC to one
defined in the MADT.  Thanks,

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Tue, Mar 9, 2010 at 4:05 PM, Alex Williamson <alex.williamson@hp.com> wrote:
>
> In my case ir_ioapic_num will match nr_ioapics, so this shouldn't
> disable on my system.
>
> The problem with the current Xen code is that there's no requirement
> that an IOAPIC is a PCI device, yet we have to describe it as a device
> scope under a DRHD to enable interrupt remapping.  That means we have to
> fill in the scope path with something, even if there's no device visible
> there.  We happen to use the path of the IOAPIC if it were exposed so we
> can keep straight what it is, but nothing requires it to be enumerable
> on the PCI bus.

I guess we probably do need to use the actual IOAPIC PCI source ID so
we can enable source ID checking in the interrupt remapping table, but
I still don't think that implies it needs to be visible on a bus walk.

>  IMHO, the only important field in an IOAPIC DRHD scope
> is the enumeration ID, which allows the OS/VMM to map the IOAPIC to one
> defined in the MADT.

So actually, I might make the argument that the purpose of IOAPIC scope is:
1) Map an MADT defined APIC ID under a DRHD
2) Provide the source ID for the IOAPIC

Using the source ID to verify the IOAPIC exists isn't valid, though I
think it would be valid to verify the APIC ID against the MADT.
Thanks,

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Tue, Mar 9, 2010 at 4:25 PM, Alex Williamson <alex.williamson@hp.com> wrote:
> On Tue, Mar 9, 2010 at 4:05 PM, Alex Williamson <alex.williamson@hp.com> wrote:
>>
>> In my case ir_ioapic_num will match nr_ioapics, so this shouldn't
>> disable on my system.
>>
>> The problem with the current Xen code is that there's no requirement
>> that an IOAPIC is a PCI device, yet we have to describe it as a device
>> scope under a DRHD to enable interrupt remapping.  That means we have to
>> fill in the scope path with something, even if there's no device visible
>> there.  We happen to use the path of the IOAPIC if it were exposed so we
>> can keep straight what it is, but nothing requires it to be enumerable
>> on the PCI bus.
>
> I guess we probably do need to use the actual IOAPIC PCI source ID so
> we can enable source ID checking in the interrupt remapping table, but
> I still don't think that implies it needs to be visible on a bus walk.
>
>>  IMHO, the only important field in an IOAPIC DRHD scope
>> is the enumeration ID, which allows the OS/VMM to map the IOAPIC to one
>> defined in the MADT.
>
> So actually, I might make the argument that the purpose of IOAPIC scope is:
> 1) Map an MADT defined APIC ID under a DRHD
> 2) Provide the source ID for the IOAPIC
>
> Using the source ID to verify the IOAPIC exists isn't valid, though I
> think it would be valid to verify the APIC ID against the MADT.

Not to beat a dead horse, but I believe my platform is exactly
following sections 8.3.1.1 of the VT-d spec for non-PCI discoverable
IOAPICs with a 2 byte path field.  This really needs to be fixed or
removed before Xen 4.0.0.  Thanks,

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Alex Williamson wrote:
> On Fri, Jan 22, 2010 at 1:47 AM, Weidong Han <weidong.han@intel.com> wrote:
>   
>> I implemented a patch and attached.
>>
>> patch description:
>>   In order to make Xen more defensive to VT-d related BIOS issue, this patch
>> ignores a DRHD if all devices under its scope are not pci discoverable, and
>> regards a DRHD as invalid and then disable whole VT-d if some devices under
>> its scope are not pci discoverable. But if iommu=force is set, it will
>> enable all DRHDs reported by BIOS, to avoid any security vulnerability with
>> malicious s/s re-enabling "supposed disabled" devices.  Pls note that we
>> don't know the devices under the "Include_all" DRHD are existent or not,
>> because the scope of "Include_all" DRHD  won't enumerate common pci device,
>> it only enumerates I/OxAPIC and HPET devices.
>>     
>
> Hi All,
>
> I have a system with what I consider to be a valid DRHD that's getting
> tripped up on this patch.  The problem is that the DRHD includes an
> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
> think Xen is being overzealous in it's validity checking and that this
> is a valid configuration.  What do others think?  Are IOAPICs a
> special case that we can allow to be non-existent on the PCI bus?
>   
Yes, IOAPIC can be not pci-discoverable. IOAPICs are only reported in 
the "Include_all" DRHD, and our patch won't check if the device is 
pci-discoverable or not for the "Include_all" DRHD. So I think the patch 
is no problem unless IOAPIC is not included in the "Include_all" DRHD. 
Can you post your boot logs?

Regards,
Weidong
> Thanks,
>
> Alex
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Wed, 2010-03-10 at 10:40 +0800, Weidong Han wrote:
> Alex Williamson wrote:
> >
> > I have a system with what I consider to be a valid DRHD that's getting
> > tripped up on this patch.  The problem is that the DRHD includes an
> > IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
> > think Xen is being overzealous in it's validity checking and that this
> > is a valid configuration.  What do others think?  Are IOAPICs a
> > special case that we can allow to be non-existent on the PCI bus?
> >   
> Yes, IOAPIC can be not pci-discoverable. IOAPICs are only reported in 
> the "Include_all" DRHD, and our patch won't check if the device is 
> pci-discoverable or not for the "Include_all" DRHD. So I think the patch 
> is no problem unless IOAPIC is not included in the "Include_all" DRHD. 
> Can you post your boot logs?

Weidong,

That's a very subtle restriction, and I'm not sure how it works in
practice.  If I have a multi-IOH system, each with VT-d hardware, each
supporting interrupt remapping, each with one or more IOAPICs below
them, how can interrupt remapping work if we can only associate an
IOAPIC with the "include all" DRHD?  I'm confused.  Thanks,

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Alex Williamson wrote:
> On Wed, 2010-03-10 at 10:40 +0800, Weidong Han wrote:
>   
>> Alex Williamson wrote:
>>     
>>> I have a system with what I consider to be a valid DRHD that's getting
>>> tripped up on this patch.  The problem is that the DRHD includes an
>>> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
>>> think Xen is being overzealous in it's validity checking and that this
>>> is a valid configuration.  What do others think?  Are IOAPICs a
>>> special case that we can allow to be non-existent on the PCI bus?
>>>   
>>>       
>> Yes, IOAPIC can be not pci-discoverable. IOAPICs are only reported in 
>> the "Include_all" DRHD, and our patch won't check if the device is 
>> pci-discoverable or not for the "Include_all" DRHD. So I think the patch 
>> is no problem unless IOAPIC is not included in the "Include_all" DRHD. 
>> Can you post your boot logs?
>>     
>
> Weidong,
>
> That's a very subtle restriction, and I'm not sure how it works in
> practice.  If I have a multi-IOH system, each with VT-d hardware, each
> supporting interrupt remapping, each with one or more IOAPICs below
> them, how can interrupt remapping work if we can only associate an
> IOAPIC with the "include all" DRHD?  I'm confused.  Thanks,
>   
Each IOH will have one "include all" DRHD which reports IOAPICs for each 
IOH.

Regards,
Weidong
> Alex
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Wed, 2010-03-10 at 11:28 +0800, Weidong Han wrote:
> Alex Williamson wrote:
> > On Wed, 2010-03-10 at 10:40 +0800, Weidong Han wrote:
> >   
> >> Alex Williamson wrote:
> >>     
> >>> I have a system with what I consider to be a valid DRHD that's getting
> >>> tripped up on this patch.  The problem is that the DRHD includes an
> >>> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
> >>> think Xen is being overzealous in it's validity checking and that this
> >>> is a valid configuration.  What do others think?  Are IOAPICs a
> >>> special case that we can allow to be non-existent on the PCI bus?
> >>>   
> >>>       
> >> Yes, IOAPIC can be not pci-discoverable. IOAPICs are only reported in 
> >> the "Include_all" DRHD, and our patch won't check if the device is 
> >> pci-discoverable or not for the "Include_all" DRHD. So I think the patch 
> >> is no problem unless IOAPIC is not included in the "Include_all" DRHD. 
> >> Can you post your boot logs?
> >>     
> >
> > Weidong,
> >
> > That's a very subtle restriction, and I'm not sure how it works in
> > practice.  If I have a multi-IOH system, each with VT-d hardware, each
> > supporting interrupt remapping, each with one or more IOAPICs below
> > them, how can interrupt remapping work if we can only associate an
> > IOAPIC with the "include all" DRHD?  I'm confused.  Thanks,
> >   
> Each IOH will have one "include all" DRHD which reports IOAPICs for each 
> IOH.

Wouldn't that imply multiple PCI segments?  The configuration I'm
looking at has multiple IOHs, all on the same PCI segment.  By my
reading of the spec, we're only allowed to declare INCLUDE_PCI_ALL for
one DRHD within the segment.  Am I incorrect?  Thanks,

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Alex Williamson wrote:
> On Wed, 2010-03-10 at 11:28 +0800, Weidong Han wrote:
>   
>> Alex Williamson wrote:
>>     
>>> On Wed, 2010-03-10 at 10:40 +0800, Weidong Han wrote:
>>>   
>>>       
>>>> Alex Williamson wrote:
>>>>     
>>>>         
>>>>> I have a system with what I consider to be a valid DRHD that's getting
>>>>> tripped up on this patch.  The problem is that the DRHD includes an
>>>>> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
>>>>> think Xen is being overzealous in it's validity checking and that this
>>>>> is a valid configuration.  What do others think?  Are IOAPICs a
>>>>> special case that we can allow to be non-existent on the PCI bus?
>>>>>   
>>>>>       
>>>>>           
>>>> Yes, IOAPIC can be not pci-discoverable. IOAPICs are only reported in 
>>>> the "Include_all" DRHD, and our patch won't check if the device is 
>>>> pci-discoverable or not for the "Include_all" DRHD. So I think the patch 
>>>> is no problem unless IOAPIC is not included in the "Include_all" DRHD. 
>>>> Can you post your boot logs?
>>>>     
>>>>         
>>> Weidong,
>>>
>>> That's a very subtle restriction, and I'm not sure how it works in
>>> practice.  If I have a multi-IOH system, each with VT-d hardware, each
>>> supporting interrupt remapping, each with one or more IOAPICs below
>>> them, how can interrupt remapping work if we can only associate an
>>> IOAPIC with the "include all" DRHD?  I'm confused.  Thanks,
>>>   
>>>       
>> Each IOH will have one "include all" DRHD which reports IOAPICs for each 
>> IOH.
>>     
>
> Wouldn't that imply multiple PCI segments?  The configuration I'm
> looking at has multiple IOHs, all on the same PCI segment.  By my
> reading of the spec, we're only allowed to declare INCLUDE_PCI_ALL for
> one DRHD within the segment.  Am I incorrect?  Thanks,
>   

Currently multiple PCI segments are not supported in Xen yet. So you 
encounter issue on multiple PCI segment system. We will support it after 
xen 4.0.

Regards,
Weidong
> Alex
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Wed, 2010-03-10 at 12:25 +0800, Weidong Han wrote:
> Alex Williamson wrote:
> > On Wed, 2010-03-10 at 11:28 +0800, Weidong Han wrote:
> >   
> >> Alex Williamson wrote:
> >>     
> >>> On Wed, 2010-03-10 at 10:40 +0800, Weidong Han wrote:
> >>>   
> >>>       
> >>>> Alex Williamson wrote:
> >>>>     
> >>>>         
> >>>>> I have a system with what I consider to be a valid DRHD that's getting
> >>>>> tripped up on this patch.  The problem is that the DRHD includes an
> >>>>> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
> >>>>> think Xen is being overzealous in it's validity checking and that this
> >>>>> is a valid configuration.  What do others think?  Are IOAPICs a
> >>>>> special case that we can allow to be non-existent on the PCI bus?
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> Yes, IOAPIC can be not pci-discoverable. IOAPICs are only reported in 
> >>>> the "Include_all" DRHD, and our patch won't check if the device is 
> >>>> pci-discoverable or not for the "Include_all" DRHD. So I think the patch 
> >>>> is no problem unless IOAPIC is not included in the "Include_all" DRHD. 
> >>>> Can you post your boot logs?
> >>>>     
> >>>>         
> >>> Weidong,
> >>>
> >>> That's a very subtle restriction, and I'm not sure how it works in
> >>> practice.  If I have a multi-IOH system, each with VT-d hardware, each
> >>> supporting interrupt remapping, each with one or more IOAPICs below
> >>> them, how can interrupt remapping work if we can only associate an
> >>> IOAPIC with the "include all" DRHD?  I'm confused.  Thanks,
> >>>   
> >>>       
> >> Each IOH will have one "include all" DRHD which reports IOAPICs for each 
> >> IOH.
> >>     
> >
> > Wouldn't that imply multiple PCI segments?  The configuration I'm
> > looking at has multiple IOHs, all on the same PCI segment.  By my
> > reading of the spec, we're only allowed to declare INCLUDE_PCI_ALL for
> > one DRHD within the segment.  Am I incorrect?  Thanks,
> >   
> 
> Currently multiple PCI segments are not supported in Xen yet. So you 
> encounter issue on multiple PCI segment system. We will support it after 
> xen 4.0.


Which is exactly why we have multiple IOHs on the *same* PCI segment on
this system.  How is it possible to support multiple IOHs, all on the
same PCI segment, each with VT-d hardware with interrupt remapping
support, each with one or more IOAPICs below them given the current
code?  We cannot list the IOAPICs only under the INCLUDE_PCI_ALL DRHD
because that wouldn't provide the right information in the right place
for interrupt remapping on the other DRHDs.  We cannot specify
INCLUDE_PCI_ALL on all of the DRHDs because the spec indicates we can
only have one INCLUDE_PCI_ALL DRHD per PCI segment (besides, we can't
have PCI sub-hierarchy scopes specified on INCLUDE_PCI_ALL DRHDs, which
means we'd have no way to associate PCI devices to a specific DRHD if
they all set this flag).

I'm inclined to believe the hardware actually works correctly if we
associate an IOAPIC to a non-INCLUDE_PCI_ALL DRHD, but this validity
checking code prevents Xen from even trying to use it.

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Alex Williamson wrote:
> On Wed, 2010-03-10 at 12:25 +0800, Weidong Han wrote:
>   
>> Alex Williamson wrote:
>>     
>>> On Wed, 2010-03-10 at 11:28 +0800, Weidong Han wrote:
>>>   
>>>       
>>>> Alex Williamson wrote:
>>>>     
>>>>         
>>>>> On Wed, 2010-03-10 at 10:40 +0800, Weidong Han wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Alex Williamson wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> I have a system with what I consider to be a valid DRHD that's getting
>>>>>>> tripped up on this patch.  The problem is that the DRHD includes an
>>>>>>> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
>>>>>>> think Xen is being overzealous in it's validity checking and that this
>>>>>>> is a valid configuration.  What do others think?  Are IOAPICs a
>>>>>>> special case that we can allow to be non-existent on the PCI bus?
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> Yes, IOAPIC can be not pci-discoverable. IOAPICs are only reported in 
>>>>>> the "Include_all" DRHD, and our patch won't check if the device is 
>>>>>> pci-discoverable or not for the "Include_all" DRHD. So I think the patch 
>>>>>> is no problem unless IOAPIC is not included in the "Include_all" DRHD. 
>>>>>> Can you post your boot logs?
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Weidong,
>>>>>
>>>>> That's a very subtle restriction, and I'm not sure how it works in
>>>>> practice.  If I have a multi-IOH system, each with VT-d hardware, each
>>>>> supporting interrupt remapping, each with one or more IOAPICs below
>>>>> them, how can interrupt remapping work if we can only associate an
>>>>> IOAPIC with the "include all" DRHD?  I'm confused.  Thanks,
>>>>>   
>>>>>       
>>>>>           
>>>> Each IOH will have one "include all" DRHD which reports IOAPICs for each 
>>>> IOH.
>>>>     
>>>>         
>>> Wouldn't that imply multiple PCI segments?  The configuration I'm
>>> looking at has multiple IOHs, all on the same PCI segment.  By my
>>> reading of the spec, we're only allowed to declare INCLUDE_PCI_ALL for
>>> one DRHD within the segment.  Am I incorrect?  Thanks,
>>>   
>>>       
>> Currently multiple PCI segments are not supported in Xen yet. So you 
>> encounter issue on multiple PCI segment system. We will support it after 
>> xen 4.0.
>>     
>
>
> Which is exactly why we have multiple IOHs on the *same* PCI segment on
> this system.  How is it possible to support multiple IOHs, all on the
> same PCI segment, each with VT-d hardware with interrupt remapping
> support, each with one or more IOAPICs below them given the current
> code?  We cannot list the IOAPICs only under the INCLUDE_PCI_ALL DRHD
> because that wouldn't provide the right information in the right place
> for interrupt remapping on the other DRHDs.  We cannot specify
> INCLUDE_PCI_ALL on all of the DRHDs because the spec indicates we can
> only have one INCLUDE_PCI_ALL DRHD per PCI segment (besides, we can't
> have PCI sub-hierarchy scopes specified on INCLUDE_PCI_ALL DRHDs, which
> means we'd have no way to associate PCI devices to a specific DRHD if
> they all set this flag).
>
> I'm inclined to believe the hardware actually works correctly if we
> associate an IOAPIC to a non-INCLUDE_PCI_ALL DRHD, but this validity
> checking code prevents Xen from even trying to use it.
>
> Alex
>   

This patch is no problem on our platform which has two IOHs, two 
IOAPICs. But there is only one DRHD, which is also INCLUDE_PCI_ALL DRHD. 
Can you post your Xen boot logs?

Regards,
Weidong

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Wed, 2010-03-10 at 15:03 +0800, Weidong Han wrote:
> 
> This patch is no problem on our platform which has two IOHs, two 
> IOAPICs. But there is only one DRHD, which is also INCLUDE_PCI_ALL DRHD. 
> Can you post your Xen boot logs?

If you have two IOHs covered by one DRHD, it doesn't sound like the IOHs
are peers of one another.  Is this a core i5 system with a DRHD in the
processor?  Of maybe you're talking about one IOH and a subordinate ICH,
which could easily be covered by one DRHD.  The topology I'm trying to
support has multiple IOHs, which are peers of one another.  Interrupts
are not routed through a "primary" IOH, so it would seem to make no
sense (and I don't believe it would work) to include all the IOAPICs
under one of them.

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Wed, 2010-03-10 at 06:56 -0700, Alex Williamson wrote:
> On Wed, 2010-03-10 at 15:03 +0800, Weidong Han wrote:
> > Can you post your Xen boot logs?

I'm not sure what you're looking for in a boot log, I think I've pretty
well described the problem.  Here's the relevant output:

(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec08000, GSI 24-47
(XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec10000, GSI 48-71
(XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
(XEN) [VT-D]dmar.c:421:   Non-existent device (84:13.0) is reported in this DRHD's scope!
(XEN) [VT-D]dmar.c:443:   The DRHD is invalid due to there are devices under its scope are not PCI discoverable! Pls try option iommu=force or iommu=workaround_bios_bug if you really want VT-d
(XEN) Failed to parse ACPI DMAR.  Disabling VT-d.

apic_id 10 is the one described under the non-INCLUDE_PCI_ALL DRHD,
which is not materialized on the PCI bus.  The DMAR effectively breaks
down to:

DMAR
 - INTR_REMAP set

DRHD0
 - INCLUDE_PCI_ALL set
 - scope includes IOAPIC 8 & 0

DRHD1
 - INCLUDE_PCI_ALL *NOT* set
 - scope includes various PCI sub-hierarchies *AND* IOAPIC 10

DRHD0 and DRHD1 are on the same PCI segment (0x0) and are peers of one
another, so it's not possible to set INCLUDE_PCI_ALL on both DRHDs, and
it's incorrect to list IOAPIC 10 under DRHD0.

Thanks,

Alex

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Alex Williamson wrote:
> On Wed, 2010-03-10 at 06:56 -0700, Alex Williamson wrote:
>   
>> On Wed, 2010-03-10 at 15:03 +0800, Weidong Han wrote:
>>     
>>> Can you post your Xen boot logs?
>>>       
>
> I'm not sure what you're looking for in a boot log, I think I've pretty
> well described the problem.  Here's the relevant output:
>
> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> (XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec08000, GSI 24-47
> (XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec10000, GSI 48-71
> (XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
> (XEN) [VT-D]dmar.c:421:   Non-existent device (84:13.0) is reported in this DRHD's scope!
> (XEN) [VT-D]dmar.c:443:   The DRHD is invalid due to there are devices under its scope are not PCI discoverable! Pls try option iommu=force or iommu=workaround_bios_bug if you really want VT-d
> (XEN) Failed to parse ACPI DMAR.  Disabling VT-d.
>
> apic_id 10 is the one described under the non-INCLUDE_PCI_ALL DRHD,
> which is not materialized on the PCI bus.  The DMAR effectively breaks
> down to:
>
> DMAR
>  - INTR_REMAP set
>
> DRHD0
>  - INCLUDE_PCI_ALL set
>  - scope includes IOAPIC 8 & 0
>
> DRHD1
>  - INCLUDE_PCI_ALL *NOT* set
>  - scope includes various PCI sub-hierarchies *AND* IOAPIC 10
>
> DRHD0 and DRHD1 are on the same PCI segment (0x0) and are peers of one
> another, so it's not possible to set INCLUDE_PCI_ALL on both DRHDs, and
> it's incorrect to list IOAPIC 10 under DRHD0.
>
> Thanks,
>
> Alex
>
>   
Alex, you are right. IOAPICs can be included in any DRHDs. Pls try 
following patch, if no problem, I will submit it.

diff -r cadf1bae9ee2 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c    Thu Feb 25 18:26:45 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c    Thu Mar 11 17:49:40 2010 +0800
@@ -437,11 +437,9 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
             else
             {
                 dprintk(XENLOG_WARNING VTDPREFIX,
-                    "  The DRHD is invalid due to there are devices under "
-                    "its scope are not PCI discoverable! Pls try option "
-                    "iommu=force or iommu=workaround_bios_bug if you "
-                    "really want VT-d\n");
-                ret = -EINVAL;
+                    "  There are devices under device scope are not PCI "
+                    "discoverable! if xen fails at VT-d enabling, pls try "
+                    "option iommu=workaround_bios_bug.\n");
             }
         }
         else

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Thu, 2010-03-11 at 10:11 +0800, Weidong Han wrote:
   
> Alex, you are right. IOAPICs can be included in any DRHDs. Pls try 
> following patch, if no problem, I will submit it.

Thanks Weidong.  This of course works, but I still get this output:

(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec08000, GSI 24-47
(XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec10000, GSI 48-71
(XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
(XEN) [VT-D]dmar.c:421:   Non-existent device (84:13.0) is reported in this DRHD's scope!
(XEN) [VT-D]dmar.c:442:   There are devices under device scope are not PCI discoverable! if xen fails at VT-d enabling, pls try option iommu=workaround_bios_bug.

So now we've effectively relegated this code to printing things that
look like errors for both actual bad DMAR tables and 100% spec compliant
tables.  At a minimum, I think these dprintks need to be reduce to info
or debug level since they're effectively just spewing out noise.  Can't
we put a tag for the device type in the list of scope devices and skip
checking discoverable PCI devices for IOAPICs?  Do we need to do the
same for HPETs?  Thanks,

Alex


> diff -r cadf1bae9ee2 xen/drivers/passthrough/vtd/dmar.c
> --- a/xen/drivers/passthrough/vtd/dmar.c    Thu Feb 25 18:26:45 2010 +0800
> +++ b/xen/drivers/passthrough/vtd/dmar.c    Thu Mar 11 17:49:40 2010 +0800
> @@ -437,11 +437,9 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
>              else
>              {
>                  dprintk(XENLOG_WARNING VTDPREFIX,
> -                    "  The DRHD is invalid due to there are devices under "
> -                    "its scope are not PCI discoverable! Pls try option "
> -                    "iommu=force or iommu=workaround_bios_bug if you "
> -                    "really want VT-d\n");
> -                ret = -EINVAL;
> +                    "  There are devices under device scope are not PCI "
> +                    "discoverable! if xen fails at VT-d enabling, pls try "
> +                    "option iommu=workaround_bios_bug.\n");
>              }
>          }
>          else
> 

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Alex Williamson wrote:
> On Thu, 2010-03-11 at 10:11 +0800, Weidong Han wrote:
>    
>   
>> Alex, you are right. IOAPICs can be included in any DRHDs. Pls try 
>> following patch, if no problem, I will submit it.
>>     
>
> Thanks Weidong.  This of course works, but I still get this output:
>
> (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> (XEN) IOAPIC[1]: apic_id 0, version 32, address 0xfec08000, GSI 24-47
> (XEN) IOAPIC[2]: apic_id 10, version 32, address 0xfec10000, GSI 48-71
> (XEN) Enabling APIC mode:  Phys.  Using 3 I/O APICs
> (XEN) [VT-D]dmar.c:421:   Non-existent device (84:13.0) is reported in this DRHD's scope!
> (XEN) [VT-D]dmar.c:442:   There are devices under device scope are not PCI discoverable! if xen fails at VT-d enabling, pls try option iommu=workaround_bios_bug.
>
> So now we've effectively relegated this code to printing things that
> look like errors for both actual bad DMAR tables and 100% spec compliant
> tables.  At a minimum, I think these dprintks need to be reduce to info
> or debug level since they're effectively just spewing out noise.  Can't
> we put a tag for the device type in the list of scope devices and skip
> checking discoverable PCI devices for IOAPICs?  Do we need to do the
> same for HPETs?  Thanks,
>   
good suggestion to check the device type. I cooked a new patch. It skips 
checking IOAPIC and HPET. pls have a try.

diff -r cadf1bae9ee2 xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c    Thu Feb 25 18:26:45 2010 +0800
+++ b/xen/drivers/passthrough/vtd/dmar.c    Thu Mar 11 19:39:45 2010 +0800
@@ -407,9 +407,15 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
     {
         u8 b, d, f;
         int i, invalid_cnt = 0;
+        struct acpi_dev_scope *acpi_scope = dev_scope_start;

         for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
         {
+            acpi_scope += (i == 0) ? 0 : acpi_scope->length;
+            if ( acpi_scope->dev_type == ACPI_DEV_IOAPIC ||
+                 acpi_scope->dev_type == ACPI_DEV_MSI_HPET )
+                continue;
+
             b = PCI_BUS(dmaru->scope.devices[i]);
             d = PCI_SLOT(dmaru->scope.devices[i]);
             f = PCI_FUNC(dmaru->scope.devices[i]);


> Alex
>
>
>   
>> diff -r cadf1bae9ee2 xen/drivers/passthrough/vtd/dmar.c
>> --- a/xen/drivers/passthrough/vtd/dmar.c    Thu Feb 25 18:26:45 2010 +0800
>> +++ b/xen/drivers/passthrough/vtd/dmar.c    Thu Mar 11 17:49:40 2010 +0800
>> @@ -437,11 +437,9 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
>>              else
>>              {
>>                  dprintk(XENLOG_WARNING VTDPREFIX,
>> -                    "  The DRHD is invalid due to there are devices under "
>> -                    "its scope are not PCI discoverable! Pls try option "
>> -                    "iommu=force or iommu=workaround_bios_bug if you "
>> -                    "really want VT-d\n");
>> -                ret = -EINVAL;
>> +                    "  There are devices under device scope are not PCI "
>> +                    "discoverable! if xen fails at VT-d enabling, pls try "
>> +                    "option iommu=workaround_bios_bug.\n");
>>              }
>>          }
>>          else
>>
>>     
>
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson]

On Thu, 2010-03-11 at 11:44 +0800, Weidong Han wrote:   
> good suggestion to check the device type. I cooked a new patch. It skips 
> checking IOAPIC and HPET. pls have a try.

I like this approach better, but the patch doesn't work as is.  The
problem is acpi_scope is getting incremented as a structure instead of
by length bytes.  It either needs to be cast on the increment, or maybe
cast on use like this:

Signed-off-by: Alex Williamson <alex.williamson@hp.com>

diff -r 132ac04cbdba xen/drivers/passthrough/vtd/dmar.c
--- a/xen/drivers/passthrough/vtd/dmar.c	Tue Mar 09 18:18:19 2010 +0000
+++ b/xen/drivers/passthrough/vtd/dmar.c	Wed Mar 10 21:46:49 2010 -0700
@@ -407,9 +407,15 @@
     {
         u8 b, d, f;
         int i, invalid_cnt = 0;
+        void *p;
 
-        for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
+        for ( i = 0, p = dev_scope_start; i < dmaru->scope.devices_cnt;
+              i++, p += ((struct acpi_dev_scope *)p)->length )
         {
+            if ( ((struct acpi_dev_scope *)p)->dev_type == ACPI_DEV_IOAPIC ||
+                 ((struct acpi_dev_scope *)p)->dev_type == ACPI_DEV_MSI_HPET )
+                continue;
+
             b = PCI_BUS(dmaru->scope.devices[i]);
             d = PCI_SLOT(dmaru->scope.devices[i]);
             f = PCI_FUNC(dmaru->scope.devices[i]);


> diff -r cadf1bae9ee2 xen/drivers/passthrough/vtd/dmar.c
> --- a/xen/drivers/passthrough/vtd/dmar.c    Thu Feb 25 18:26:45 2010 +0800
> +++ b/xen/drivers/passthrough/vtd/dmar.c    Thu Mar 11 19:39:45 2010 +0800
> @@ -407,9 +407,15 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
>      {
>          u8 b, d, f;
>          int i, invalid_cnt = 0;
> +        struct acpi_dev_scope *acpi_scope = dev_scope_start;
> 
>          for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
>          {
> +            acpi_scope += (i == 0) ? 0 : acpi_scope->length;
> +            if ( acpi_scope->dev_type == ACPI_DEV_IOAPIC ||
> +                 acpi_scope->dev_type == ACPI_DEV_MSI_HPET )
> +                continue;
> +
>              b = PCI_BUS(dmaru->scope.devices[i]);
>              d = PCI_SLOT(dmaru->scope.devices[i]);
>              f = PCI_FUNC(dmaru->scope.devices[i]);
> 
> 

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Alex Williamson wrote:
> On Thu, 2010-03-11 at 11:44 +0800, Weidong Han wrote:   
>   
>> good suggestion to check the device type. I cooked a new patch. It skips 
>> checking IOAPIC and HPET. pls have a try.
>>     
>
> I like this approach better, but the patch doesn't work as is.  The
> problem is acpi_scope is getting incremented as a structure instead of
> by length bytes.  It either needs to be cast on the increment, or maybe
> cast on use like this:
>
> Signed-off-by: Alex Williamson <alex.williamson@hp.com>
>
> diff -r 132ac04cbdba xen/drivers/passthrough/vtd/dmar.c
> --- a/xen/drivers/passthrough/vtd/dmar.c	Tue Mar 09 18:18:19 2010 +0000
> +++ b/xen/drivers/passthrough/vtd/dmar.c	Wed Mar 10 21:46:49 2010 -0700
> @@ -407,9 +407,15 @@
>      {
>          u8 b, d, f;
>          int i, invalid_cnt = 0;
> +        void *p;
>  
> -        for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
> +        for ( i = 0, p = dev_scope_start; i < dmaru->scope.devices_cnt;
> +              i++, p += ((struct acpi_dev_scope *)p)->length )
>          {
> +            if ( ((struct acpi_dev_scope *)p)->dev_type == ACPI_DEV_IOAPIC ||
> +                 ((struct acpi_dev_scope *)p)->dev_type == ACPI_DEV_MSI_HPET )
> +                continue;
> +
>              b = PCI_BUS(dmaru->scope.devices[i]);
>              d = PCI_SLOT(dmaru->scope.devices[i]);
>              f = PCI_FUNC(dmaru->scope.devices[i]);
>   

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

Regards,
Weidong
>
>   
>> diff -r cadf1bae9ee2 xen/drivers/passthrough/vtd/dmar.c
>> --- a/xen/drivers/passthrough/vtd/dmar.c    Thu Feb 25 18:26:45 2010 +0800
>> +++ b/xen/drivers/passthrough/vtd/dmar.c    Thu Mar 11 19:39:45 2010 +0800
>> @@ -407,9 +407,15 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
>>      {
>>          u8 b, d, f;
>>          int i, invalid_cnt = 0;
>> +        struct acpi_dev_scope *acpi_scope = dev_scope_start;
>>
>>          for ( i = 0; i < dmaru->scope.devices_cnt; i++ )
>>          {
>> +            acpi_scope += (i == 0) ? 0 : acpi_scope->length;
>> +            if ( acpi_scope->dev_type == ACPI_DEV_IOAPIC ||
>> +                 acpi_scope->dev_type == ACPI_DEV_MSI_HPET )
>> +                continue;
>> +
>>              b = PCI_BUS(dmaru->scope.devices[i]);
>>              d = PCI_SLOT(dmaru->scope.devices[i]);
>>              f = PCI_FUNC(dmaru->scope.devices[i]);
>>
>>
>>     
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Andrew Lyon]

On Thu, Jan 21, 2010 at 2:17 PM, Sander Eikelenboom
<linux@eikelenboom.it> wrote:
> Hello Weidong,
>
> The problem is most vendor's just don't fix it and ignore the problem completely.
> Most often hiding them selves behind: come back when it's a problem with Microsoft Windows, that the only single thing we support (and no other software, so no vmware, no xen, no linux, perhaps even no hypervisor)

Supermicro were fairly cooperative but they wanted to know *exactly*
what was wrong, i.e. wanted me to show them the incorrect values and
how to fix them, I tried to work it out but failed :(.

I had the same problem on a Dell system, who went down the "we dont
support xen" route, but again they would have been willing to take it
further if I could show them which values were incorrect.

If we had a diagnostic tool that could verify the settings and output
detailed explanations of any problems that would really help to give
manufacturers the info they need to fix the bios.

Andy

> Well I don't know if the virtual pc in windows 7 supports an iommu now, but it didn't in the past as far as i know, so any complain bounces off, and there it all seems to end for them.
>
> Besides that i don't know if they do know what the problems with there implementation in BIOS is when someone reports it.
> I think some behind the scenes pressure from Intel to vendors might help to solve some of them.
> (my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for that) also suffers RMRR problem when another graphics card is inserted which switches off the IGD).
>
> Although i think in my case your patch will work around that for me. Perhaps a third option is needed, which does all the workarounds possible and warns about potential security problem when requested ?
>
> --
> Sander
>
>
>
>
>
>
> Thursday, January 21, 2010, 1:46:39 PM, you wrote:
>
>> Noboru Iwamatsu wrote:
>>> Hi Weidong,
>>>
>>> I re-send the DRHD-fix patch.
>>>
>>> If DRHD does not have existent devices, ignore it.
>>> If DRHD has both existent and non-existent devices, consider it invalid
>>> and not register.
>>>
>
>> Although you patch workarounds your buggy BIOS, but we still need to
>> enable it for security purpose as I mentioned in previous mail. We
>> needn't workaround / fix all BIOS issues in software. I think security
>> is more important for this specific BIOS issue. Did you report the BIOS
>> issue to your OEM vendor? maybe it's better to get it fixed in BIOS.
>
>> Regards,
>> Weidong
>>> According to this patch and yours, my machine successfully booted
>>> with vt-d enabled.
>>>
>>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>>
>>>
>>>
>>>> Keir Fraser wrote:
>>>>
>>>>> On 21/01/2010 10:19, "Weidong Han" <weidong.han@intel.com> wrote:
>>>>>
>>>>>
>>>>>>> Sorry this is typo.
>>>>>>> I mean:
>>>>>>> So, I think RMRR that has no-existent device is "invalid"
>>>>>>> and whole RMRR should be ignored.
>>>>>>>
>>>>>> looks reasonable.
>>>>>>
>>>>>> Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
>>>>>> patch?
>>>>>>
>>>>> Merge them up, re-send with both sign-off and acked-by all in one email.
>>>>>
>>>>> Thanks,
>>>>> Keir
>>>>>
>>>>>
>>>> Sorry, I disagree with Noboru after thinking it again. If the RMRR has
>>>> both no-existent device and also has existent devices in its scope, we
>>>> should not ignore it because the existent devices under its scope will
>>>> be impacted without the RMRR. so I suggest to print a warning instead of
>>>> ignore it. Attached a patch for it.
>>>>
>>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>>>
>>>
>>>
>
>
>
>
>
>
> --
> Best regards,
>  Sander                            mailto:linux@eikelenboom.it
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: [PATCH] VT-d: improve RMRR validity checking

[Keir Fraser]

On 21/01/2010 12:19, "Noboru Iwamatsu" <n_iwamatsu@jp.fujitsu.com> wrote:

> I re-send the DRHD-fix patch.
> 
> If DRHD does not have existent devices, ignore it.
> If DRHD has both existent and non-existent devices, consider it invalid
> and not register.

What happens if you register a DRHD with some but not all devices existing?
Do bad things happen on some systems?

 -- Keir

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

Hi,

>> I re-send the DRHD-fix patch.
>>
>> If DRHD does not have existent devices, ignore it.
>> If DRHD has both existent and non-existent devices, consider it invalid
>> and not register.
>
> What happens if you register a DRHD with some but not all devices existing?
> Do bad things happen on some systems?

In the case I have posted the log, DRHD has only non-existent devices,
and maybe its info is invalid. So iommu_enable_translation() failed and
became panic.

When DRHD has at least one existent device, I have not seen,
its info might be correct. I cannot judge it, so disabled at the patch.

Even if this DRHD-ignore patch is not accepted, we should validate the
DRHD and stop the PANIC.

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Noboru Iwamatsu wrote:
> Hi,
>
> After registered invalid DRHDs, Xen hangs in boot time.
>   

Can you post the logs?

Regards,
Weidong
> About RMRR, I understood the logic.
> In my mainboard, unfortunately, RMRR has non-existent device under
> its scope, and to make matters worse, the RMRR range is invalid.
> So, I think RMRR that has no-existent device is valid.
>
> How do you think about these?
>
>   
>> Hi Noboru,
>>
>> You should not ignore DRHD even if devices under its scope are not pci discoverable. For the sake of security, we still enable these DRHDs but don't set any context mappings. In that case, any DMA that comes from these "supposedly disabled" devices will get blocked by VT-d, and hence avoid any security vulnerability with malicious s/w re-enabling these devices.
>>
>> You RMRR validity fixing is wrong. My RMRR patch is no problem. Pls note that the RMRR checking logic is:
>> 	If all devices under RMRR's scope are not pci discoverable
>> 		Ignore the RMRR
>> 	Else if base_address>  end_address
>> 		Return error
>> 	Else
>> 		Register RMRR
>>
>> Regards,
>> Weidong
>> 		
>>
>> -----Original Message-----
>> From: Noboru Iwamatsu [mailto:n_iwamatsu@jp.fujitsu.com]
>> Sent: Thursday, January 21, 2010 4:26 PM
>> To: Han, Weidong
>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com
>> Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>
>> Hi,
>>
>> Some Q35 mainboard that has buggy BIOS, I have one of this, reports invalid DRHD in addition to the invalid RMRR.
>>
>> Attached patch fixes this DRHD issue in the same way as RMRR.
>> And also, I fixed RMRR validity checking loop.
>>
>> Noboru.
>>
>> Signed-off-by: Noboru Iwamatsu<n_iwamatsu@jp.fujitsu.com>
>>
>>
>> -------- Original Message  --------
>> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>> From: Han, Weidong<weidong.han@intel.com>
>> To: xen-devel@lists.xensource.com<xen-devel@lists.xensource.com>
>> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>>
>>     
>>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is set incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the device under its scope are not pci discoverable, because the RMRR won't be used by non-existed or disabled devices.
>>>
>>> This patch ignores the RMRR if the device under its scope are not pci discoverable, and only checks the validity of RMRRs that are actually used. In order to avoid duplicate pci device detection code, this patch defines a function pci_device_detect for it.
>>>
>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>       
>
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

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

Hi Weidong,

Here is the log.
Xen version is:
xen-unstable c/s 20829 + return.patch + rmrr.patch

Regards,
Noboru

> Noboru Iwamatsu wrote:
>> Hi,
>>
>> After registered invalid DRHDs, Xen hangs in boot time.
>
> Can you post the logs?
>
> Regards,
> Weidong
>> About RMRR, I understood the logic.
>> In my mainboard, unfortunately, RMRR has non-existent device under
>> its scope, and to make matters worse, the RMRR range is invalid.
>> So, I think RMRR that has no-existent device is valid.
>>
>> How do you think about these?
>>
>>> Hi Noboru,
>>>
>>> You should not ignore DRHD even if devices under its scope are not
>>> pci discoverable. For the sake of security, we still enable these
>>> DRHDs but don't set any context mappings. In that case, any DMA that
>>> comes from these "supposedly disabled" devices will get blocked by
>>> VT-d, and hence avoid any security vulnerability with malicious s/w
>>> re-enabling these devices.
>>>
>>> You RMRR validity fixing is wrong. My RMRR patch is no problem. Pls
>>> note that the RMRR checking logic is:
>>> If all devices under RMRR's scope are not pci discoverable
>>> Ignore the RMRR
>>> Else if base_address> end_address
>>> Return error
>>> Else
>>> Register RMRR
>>>
>>> Regards,
>>> Weidong
>>>
>>>
>>> -----Original Message-----
>>> From: Noboru Iwamatsu [mailto:n_iwamatsu@jp.fujitsu.com]
>>> Sent: Thursday, January 21, 2010 4:26 PM
>>> To: Han, Weidong
>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com
>>> Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>>
>>> Hi,
>>>
>>> Some Q35 mainboard that has buggy BIOS, I have one of this, reports
>>> invalid DRHD in addition to the invalid RMRR.
>>>
>>> Attached patch fixes this DRHD issue in the same way as RMRR.
>>> And also, I fixed RMRR validity checking loop.
>>>
>>> Noboru.
>>>
>>> Signed-off-by: Noboru Iwamatsu<n_iwamatsu@jp.fujitsu.com>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>> From: Han, Weidong<weidong.han@intel.com>
>>> To: xen-devel@lists.xensource.com<xen-devel@lists.xensource.com>
>>> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>>>
>>>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is
>>>> set incorrectly in BIOS rigorously. But, actually we can ignore the
>>>> RMRR if the device under its scope are not pci discoverable, because
>>>> the RMRR won't be used by non-existed or disabled devices.
>>>>
>>>> This patch ignores the RMRR if the device under its scope are not
>>>> pci discoverable, and only checks the validity of RMRRs that are
>>>> actually used. In order to avoid duplicate pci device detection
>>>> code, this patch defines a function pci_device_detect for it.
>>>>
>>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>
>>
>


[-- Attachment #2: xen-serial.log --]
[-- Type: text/plain, Size: 12272 bytes --]


 __  __            _  _    ___   ___              ____
 \ \/ /___ _ __   | || |  / _ \ / _ \    _ __ ___|___ \    _ __  _ __ ___
  \  // _ \ '_ \  | || |_| | | | | | |__| '__/ __| __) |__| '_ \| '__/ _ \
  /  \  __/ | | | |__   _| |_| | |_| |__| | | (__ / __/|__| |_) | | |  __/
 /_/\_\___|_| |_|    |_|(_)___(_)___/   |_|  \___|_____|  | .__/|_|  \___|
                                                          |_|
(XEN) Xen version 4.0.0-rc2-pre (noboru@) (gcc version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC) ) Thu Jan 21 18:22:09 JST 2010
(XEN) Latest ChangeSet: Thu Jan 21 14:08:42 2010 +0900 20859:bbad08b156e9
(XEN) Command line: com1=115200,8n1 vga=text-80x25 console=com1,vga iommu=1 noreboot loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x0
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009e400 (usable)
(XEN)  000000000009e400 - 00000000000a0000 (reserved)
(XEN)  00000000000f0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bfe90000 (usable)
(XEN)  00000000bfe90000 - 00000000bfee3000 (ACPI NVS)
(XEN)  00000000bfee3000 - 00000000bfef0000 (ACPI data)
(XEN)  00000000bfef0000 - 00000000bff00000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000013c000000 (usable)
(XEN) ACPI: RSDP 000F8B70, 0024 (r2 FUJ   )
(XEN) ACPI: XSDT BFEE3080, 006C (r1 FUJ    PC       30383232 AWRD        0)
(XEN) ACPI: FACP BFEE8040, 00F4 (r3 FUJ    PC       30383232 AWRD        0)
(XEN) ACPI: DSDT BFEE3200, 4E24 (r1 FUJ    AWRDACPI    80202 MSFT  3000000)
(XEN) ACPI: FACS BFE90000, 0040
(XEN) ACPI: SLIC BFEE8240, 0176 (r1 FUJ    PC       30383232 AWRD  1010101)
(XEN) ACPI: ASF! BFEE8440, 008A (r16 FUJ    PC       30383232 AWRD        0)
(XEN) ACPI: HPET BFEE83C0, 0038 (r1 FUJ    PC       30383232 AWRD       98)
(XEN) ACPI: MCFG BFEE8400, 003C (r1 FUJ    PC       30383232 AWRD        0)
(XEN) ACPI: APIC BFEE8140, 0084 (r1 FUJ    PC       30383232 AWRD        0)
(XEN) ACPI: SSDT BFEE8E20, 07EF (r1  PmRef    CpuPm     3000 INTL 20061109)
(XEN) ACPI: BOOT BFEE9640, 0028 (r1 FUJ    PC       30383232 AWRD        0)
(XEN) ACPI: DMAR BFEE9680, 0110 (r1 IntelR AWRDACPI 322E3030 DRWA        2)
(XEN) System RAM: 3910MB (4004452kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000013c000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000f44a0
(XEN) DMI 2.5 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0]
(XEN) ACPI:                  wakeup_vec[bfe9000c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 7:7 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x03] enabled)
(XEN) Processor #3 7:7 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 7:7 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
(XEN) Processor #2 7:7 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
(XEN) [VT-D]dmar.c:580: Host address width 36
(XEN) [VT-D]dmar.c:589: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:374:   dmaru->address = fed90000
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1b.0
(XEN) [VT-D]dmar.c:589: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:374:   dmaru->address = fed91000
(XEN) [VT-D]dmar.c:326:   endpoint: 0:2.1
(XEN) [VT-D]dmar.c:589: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:374:   dmaru->address = fed92000
(XEN) [VT-D]dmar.c:326:   endpoint: 0:3.0
(XEN) [VT-D]dmar.c:326:   endpoint: 0:3.2
(XEN) [VT-D]dmar.c:326:   endpoint: 0:3.3
(XEN) [VT-D]dmar.c:589: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:374:   dmaru->address = fed93000
(XEN) [VT-D]dmar.c:386:   flags: INCLUDE_ALL
(XEN) [VT-D]dmar.c:593: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1d.0
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1d.1
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1d.2
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1d.7
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1a.0
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1a.1
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1a.2
(XEN) [VT-D]dmar.c:326:   endpoint: 0:1a.7
(XEN) [VT-D]dmar.c:484:   RMRR region: base_addr bfef0000 end_address bfefffff
(XEN) [VT-D]dmar.c:593: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:425:   RMRR address range not in reserved memory base = c0000000 end = bfffffff; iommu_inclusive_mapping=1 parameter may be needed.
(XEN) [VT-D]dmar.c:326:   endpoint: 0:2.1
(XEN) [VT-D]dmar.c:469:   Ignore the RMRR (c0000000, bfffffff) due to devices under its scope are not PCI discoverable!
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Detected 2660.356 MHz processor.
(XEN) Initing memory sharing.
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 6144K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) Intel machine check reporting enabled on CPU#0.
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) CMCI: CPU0 has no CMCI support
(XEN) [VT-D]iommu.c:1062: drhd->address = fed92000
(XEN) [VT-D]iommu.c:1063: iommu->reg = ffff82c3fff57000
(XEN) [VT-D]iommu.c:1062: drhd->address = fed91000
(XEN) [VT-D]iommu.c:1063: iommu->reg = ffff82c3fff56000
(XEN) [VT-D]iommu.c:1062: drhd->address = fed90000
(XEN) [VT-D]iommu.c:1063: iommu->reg = ffff82c3fff55000
(XEN) [VT-D]iommu.c:1062: drhd->address = fed93000
(XEN) [VT-D]iommu.c:1063: iommu->reg = ffff82c3fff54000
(XEN) Intel VT-d Snoop Control not supported.
(XEN) Intel VT-d DMA Passthrough not supported.
(XEN) Intel VT-d Queued Invalidation not supported.
(XEN) Intel VT-d Interrupt Remapping not supported.
(XEN) I/O virtualisation enabled
(XEN) I/O virtualisation for PV guests disabled
(XEN) CPU0: Intel(R) Core(TM)2 Quad  CPU   Q9450  @ 2.66GHz stepping 07
(XEN) Booting processor 1/3 eip 8c000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 6144K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 3
(XEN) HVM: ASIDs disabled.
(XEN) Intel machine check reporting enabled on CPU#1.
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Intel(R) Core(TM)2 Quad  CPU   Q9450  @ 2.66GHz stepping 07
(XEN) Booting processor 2/1 eip 8c000
(XEN) Initializing CPU#2
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 6144K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) HVM: ASIDs disabled.
(XEN) Intel machine check reporting enabled on CPU#2.
(XEN) CPU2: Thermal monitoring enabled (TM2)
(XEN) CMCI: CPU2 has no CMCI support
(XEN) CPU2: Intel(R) Core(TM)2 Quad  CPU   Q9450  @ 2.66GHz stepping 07
(XEN) Booting processor 3/2 eip 8c000
(XEN) Initializing CPU#3
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 6144K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 2
(XEN) HVM: ASIDs disabled.
(XEN) Intel machine check reporting enabled on CPU#3.
(XEN) CPU3: Thermal monitoring enabled (TM2)
(XEN) CMCI: CPU3 has no CMCI support
(XEN) CPU3: Intel(R) Core(TM)2 Quad  CPU   Q9450  @ 2.66GHz stepping 07
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) checking TSC synchronization across 4 CPUs: passed.
(XEN) Platform timer is 14.318MHz HPET
(XEN) microcode.c:73:d32767 microcode: CPU1 resumed
(XEN) microcode.c:73:d32767 microcode: CPU3 resumed
(XEN) Brought up 4 CPUs
(XEN) microcode.c:73:d32767 microcode: CPU2 resumed
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:0.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:0.0:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:3.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:3.0:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:3.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:3.2:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:3.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:3.3:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:19.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:19.0:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1a.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1a.0:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1a.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1a.1:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1a.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1a.2:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1a.7
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1a.7:  no extended config
(XEN) [VT-D]iommu.c:1299:d32767 domain_context_mapping:PCIe: bdf = 0:1b.0
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1d.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1d.0:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1d.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1d.1:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1d.2
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1d.2:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1d.7
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1d.7:  no extended config
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1e.0:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1f.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1f.0:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1f.2
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 0:1f.3
(XEN) [VT-D]mmconfig-shared.c:460: next cap:0:1f.3:  no extended config
(XEN) [VT-D]iommu.c:1299:d32767 domain_context_mapping:PCIe: bdf = 1:0.0
(XEN) [VT-D]iommu.c:1299:d32767 domain_context_mapping:PCIe: bdf = 1:0.1
(XEN) [VT-D]mmconfig-shared.c:460: next cap:1:0.1:  no extended config
(XEN) [VT-D]iommu.c:1299:d32767 domain_context_mapping:PCIe: bdf = 3:0.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:3:0.0:  no extended config
(XEN) [VT-D]iommu.c:1306:d32767 domain_context_mapping:PCI: bdf = 4:5.0
(XEN) [VT-D]mmconfig-shared.c:460: next cap:4:5.0:  no extended config
(XEN) [VT-D]iommu.c:684: iommu_enable_translation: iommu->reg = ffff82c3fff57000
(XEN) [VT-D]iommu.c:684: iommu_enable_translation: iommu->reg = ffff82c3fff56000
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) iommu.c:691:iommu_enable_translation: DMAR hardware is malfunctional
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)


[-- 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] VT-d: improve RMRR validity checking

[Weidong Han]

Seems you inserted a discrete gfx card, then the IGD is disabled. right? 
can you provide the platform info and  BIOS version?

Regards,
Weidong

Noboru Iwamatsu wrote:
> Hi Weidong,
>
> Here is the log.
> Xen version is:
> xen-unstable c/s 20829 + return.patch + rmrr.patch
>
> Regards,
> Noboru
>
>   
>> Noboru Iwamatsu wrote:
>>     
>>> Hi,
>>>
>>> After registered invalid DRHDs, Xen hangs in boot time.
>>>       
>> Can you post the logs?
>>
>> Regards,
>> Weidong
>>     
>>> About RMRR, I understood the logic.
>>> In my mainboard, unfortunately, RMRR has non-existent device under
>>> its scope, and to make matters worse, the RMRR range is invalid.
>>> So, I think RMRR that has no-existent device is valid.
>>>
>>> How do you think about these?
>>>
>>>       
>>>> Hi Noboru,
>>>>
>>>> You should not ignore DRHD even if devices under its scope are not
>>>> pci discoverable. For the sake of security, we still enable these
>>>> DRHDs but don't set any context mappings. In that case, any DMA that
>>>> comes from these "supposedly disabled" devices will get blocked by
>>>> VT-d, and hence avoid any security vulnerability with malicious s/w
>>>> re-enabling these devices.
>>>>
>>>> You RMRR validity fixing is wrong. My RMRR patch is no problem. Pls
>>>> note that the RMRR checking logic is:
>>>> If all devices under RMRR's scope are not pci discoverable
>>>> Ignore the RMRR
>>>> Else if base_address> end_address
>>>> Return error
>>>> Else
>>>> Register RMRR
>>>>
>>>> Regards,
>>>> Weidong
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Noboru Iwamatsu [mailto:n_iwamatsu@jp.fujitsu.com]
>>>> Sent: Thursday, January 21, 2010 4:26 PM
>>>> To: Han, Weidong
>>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com
>>>> Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>>>
>>>> Hi,
>>>>
>>>> Some Q35 mainboard that has buggy BIOS, I have one of this, reports
>>>> invalid DRHD in addition to the invalid RMRR.
>>>>
>>>> Attached patch fixes this DRHD issue in the same way as RMRR.
>>>> And also, I fixed RMRR validity checking loop.
>>>>
>>>> Noboru.
>>>>
>>>> Signed-off-by: Noboru Iwamatsu<n_iwamatsu@jp.fujitsu.com>
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>>> From: Han, Weidong<weidong.han@intel.com>
>>>> To: xen-devel@lists.xensource.com<xen-devel@lists.xensource.com>
>>>> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>>>>
>>>>         
>>>>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is
>>>>> set incorrectly in BIOS rigorously. But, actually we can ignore the
>>>>> RMRR if the device under its scope are not pci discoverable, because
>>>>> the RMRR won't be used by non-existed or disabled devices.
>>>>>
>>>>> This patch ignores the RMRR if the device under its scope are not
>>>>> pci discoverable, and only checks the validity of RMRRs that are
>>>>> actually used. In order to avoid duplicate pci device detection
>>>>> code, this patch defines a function pci_device_detect for it.
>>>>>
>>>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>>           
>>>       
>
>   

Re: [PATCH] VT-d: improve RMRR validity checking

[Noboru Iwamatsu]

 > Seems you inserted a discrete gfx card, then the IGD is disabled. right?

Yes, I'm using Q35 M/B with external PCIe graphic card.
IGD of the M/B is disabled automatically, however,
the entry of its DRHD and RMRR are found.

This issue only occurs when using external VGA.
The rough solution is to ignore the DRHD/RMRR including
BDF[0.2.0] or BDF[0.2.1].
I had been doing this way.

 > can you provide the platform info and BIOS version?

My platform is Fujitsu's private one.

Regards,
Noboru.

> Seems you inserted a discrete gfx card, then the IGD is disabled. right?
> can you provide the platform info and BIOS version?
>
> Regards,
> Weidong
>
> Noboru Iwamatsu wrote:
>> Hi Weidong,
>>
>> Here is the log.
>> Xen version is:
>> xen-unstable c/s 20829 + return.patch + rmrr.patch
>>
>> Regards,
>> Noboru
>>
>>> Noboru Iwamatsu wrote:
>>>> Hi,
>>>>
>>>> After registered invalid DRHDs, Xen hangs in boot time.
>>> Can you post the logs?
>>>
>>> Regards,
>>> Weidong
>>>> About RMRR, I understood the logic.
>>>> In my mainboard, unfortunately, RMRR has non-existent device under
>>>> its scope, and to make matters worse, the RMRR range is invalid.
>>>> So, I think RMRR that has no-existent device is valid.
>>>>
>>>> How do you think about these?
>>>>
>>>>> Hi Noboru,
>>>>>
>>>>> You should not ignore DRHD even if devices under its scope are not
>>>>> pci discoverable. For the sake of security, we still enable these
>>>>> DRHDs but don't set any context mappings. In that case, any DMA that
>>>>> comes from these "supposedly disabled" devices will get blocked by
>>>>> VT-d, and hence avoid any security vulnerability with malicious s/w
>>>>> re-enabling these devices.
>>>>>
>>>>> You RMRR validity fixing is wrong. My RMRR patch is no problem. Pls
>>>>> note that the RMRR checking logic is:
>>>>> If all devices under RMRR's scope are not pci discoverable
>>>>> Ignore the RMRR
>>>>> Else if base_address> end_address
>>>>> Return error
>>>>> Else
>>>>> Register RMRR
>>>>>
>>>>> Regards,
>>>>> Weidong
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Noboru Iwamatsu [mailto:n_iwamatsu@jp.fujitsu.com]
>>>>> Sent: Thursday, January 21, 2010 4:26 PM
>>>>> To: Han, Weidong
>>>>> Cc: xen-devel@lists.xensource.com; keir.fraser@eu.citrix.com
>>>>> Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>>>>
>>>>> Hi,
>>>>>
>>>>> Some Q35 mainboard that has buggy BIOS, I have one of this, reports
>>>>> invalid DRHD in addition to the invalid RMRR.
>>>>>
>>>>> Attached patch fixes this DRHD issue in the same way as RMRR.
>>>>> And also, I fixed RMRR validity checking loop.
>>>>>
>>>>> Noboru.
>>>>>
>>>>> Signed-off-by: Noboru Iwamatsu<n_iwamatsu@jp.fujitsu.com>
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>>>>> From: Han, Weidong<weidong.han@intel.com>
>>>>> To: xen-devel@lists.xensource.com<xen-devel@lists.xensource.com>
>>>>> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>>>>>
>>>>>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is
>>>>>> set incorrectly in BIOS rigorously. But, actually we can ignore the
>>>>>> RMRR if the device under its scope are not pci discoverable, because
>>>>>> the RMRR won't be used by non-existed or disabled devices.
>>>>>>
>>>>>> This patch ignores the RMRR if the device under its scope are not
>>>>>> pci discoverable, and only checks the validity of RMRRs that are
>>>>>> actually used. In order to avoid duplicate pci device detection
>>>>>> code, this patch defines a function pci_device_detect for it.
>>>>>>
>>>>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>
>

Re: [PATCH] VT-d: improve RMRR validity checking

[Andrew Lyon]

On Thu, Jan 21, 2010 at 8:25 AM, Noboru Iwamatsu
<n_iwamatsu@jp.fujitsu.com> wrote:
> Hi,
>
> Some Q35 mainboard that has buggy BIOS, I have one of this,
> reports invalid DRHD in addition to the invalid RMRR.
>
> Attached patch fixes this DRHD issue in the same way as RMRR.
> And also, I fixed RMRR validity checking loop.
>
> Noboru.
>
> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>
>
> -------- Original Message  --------
> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
> From: Han, Weidong <weidong.han@intel.com>
> To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com>
> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>
>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is set
>> incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the
>> device under its scope are not pci discoverable, because the RMRR won't be
>> used by non-existed or disabled devices.
>>
>> This patch ignores the RMRR if the device under its scope are not pci
>> discoverable, and only checks the validity of RMRRs that are actually used.
>> In order to avoid duplicate pci device detection code, this patch defines a
>> function pci_device_detect for it.
>>
>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

I have a Supermicro X7DWA-N system which requires
iommu_inclusive_mapping=1 in order to boot Xen successfully with iommu
enabled, I am going to try these patches to see if the workaround is
still necessary but I would also like to ask for some help in getting
the bios fixed properly , I contacted Supermicro about this issue last
year and they said they would fix it but they wanted details of
exactly what was wrong, I tried to figure it out by using acpidump and
reading the rmrr spec but I failed to make sense of it, perhaps you
could have a quick look at this dump and let me know if there is
anything obviously wrong?


acpidump
DSDT @ 0xbff5b868
  0000: 44 53 44 54 10 4a 00 00 01 2e 49 6e 74 65 6c 00  DSDT.J....Intel.
  0010: 53 45 41 42 55 52 47 20 00 00 04 06 4d 53 46 54  SEABURG ....MSFT
  0020: 01 00 00 03 5b 80 52 43 52 42 00 0c 00 c0 d1 fe  ....[.RCRB......
  0030: 0b 00 40 5b 81 43 05 52 43 52 42 13 00 80 00 08  ..@[.C.RCRB.....
  0040: 00 80 00 10 00 80 02 02 48 50 41 53 02 00 05 48  ........HPAS...H
  0050: 50 41 45 01 00 48 09 00 01 50 41 54 44 01 53 41  PAE..H...PATD.SA
  0060: 54 44 01 53 4d 42 44 01 41 5a 41 44 01 41 39 37  TD.SMBD.AZAD.A97
  0070: 44 01 00 0a 52 45 31 44 01 52 45 32 44 01 52 45  D...RE1D.RE2D.RE
  0080: 33 44 01 52 45 34 44 01 10 4d 23 5f 47 50 45 14  3D.RE4D..M#_GPE.
  0090: 2a 5f 4c 30 33 00 70 0a 03 5c 2f 03 5f 53 42 5f  *_L03.p..\/._SB_
  00a0: 50 43 49 30 50 54 38 30 86 5c 2f 03 5f 53 42 5f  PCI0PT80.\/._SB_
  00b0: 50 43 49 30 55 53 42 31 0a 02 14 2a 5f 4c 30 34  PCI0USB1...*_L04
  00c0: 00 70 0a 04 5c 2f 03 5f 53 42 5f 50 43 49 30 50  .p..\/._SB_PCI0P
  00d0: 54 38 30 86 5c 2f 03 5f 53 42 5f 50 43 49 30 55  T80.\/._SB_PCI0U
  00e0: 53 42 32 0a 02 14 2a 5f 4c 30 35 00 70 0a 05 5c  SB2...*_L05.p..\
  00f0: 2f 03 5f 53 42 5f 50 43 49 30 50 54 38 30 86 5c  /._SB_PCI0PT80.\
  0100: 2f 03 5f 53 42 5f 50 43 49 30 41 5a 4c 41 0a 02  /._SB_PCI0AZLA..
  0110: 14 4d 04 5f 4c 30 38 00 70 0a 08 5c 2f 03 5f 53  .M._L08.p..\/._S
  0120: 42 5f 50 43 49 30 50 54 38 30 86 5c 2f 05 5f 53  B_PCI0PT80.\/._S
  0130: 42 5f 50 43 49 30 4c 50 43 30 53 49 4f 5f 43 4f  B_PCI0LPC0SIO_CO
  0140: 4d 31 0a 02 86 5c 2f 05 5f 53 42 5f 50 43 49 30  M1...\/._SB_PCI0
  0150: 4c 50 43 30 53 49 4f 5f 43 4f 4d 32 0a 02 14 49  LPC0SIO_COM2...I
  0160: 06 5f 4c 30 39 00 70 0a 09 5c 2f 03 5f 53 42 5f  ._L09.p..\/._SB_
  0170: 50 43 49 30 50 54 38 30 86 5c 2f 03 5f 53 42 5f  PCI0PT80.\/._SB_
  0180: 50 43 49 30 50 30 50 31 0a 02 86 5c 2f 03 5f 53  PCI0P0P1...\/._S
  0190: 42 5f 50 43 49 30 50 30 50 35 0a 02 86 5c 2f 05  B_PCI0P0P5...\/.
  01a0: 5f 53 42 5f 50 43 49 30 50 30 50 39 42 4d 46 30  _SB_PCI0P0P9BMF0
  01b0: 42 50 44 30 0a 02 86 5c 2f 03 5f 53 42 5f 50 43  BPD0...\/._SB_PC
  01c0: 49 30 50 45 58 30 0a 02 14 2a 5f 4c 30 42 00 70  I0PEX0...*_L0B.p
  01d0: 0a 0b 5c 2f 03 5f 53 42 5f 50 43 49 30 50 54 38  ..\/._SB_PCI0PT8
  01e0: 30 86 5c 2f 03 5f 53 42 5f 50 43 49 30 50 43 49  0.\/._SB_PCI0PCI
  01f0: 42 0a 02 14 2a 5f 4c 30 43 00 70 0a 0c 5c 2f 03  B...*_L0C.p..\/.
  0200: 5f 53 42 5f 50 43 49 30 50 54 38 30 86 5c 2f 03  _SB_PCI0PT80.\/.
  0210: 5f 53 42 5f 50 43 49 30 55 53 42 33 0a 02 14 2a  _SB_PCI0USB3...*
  0220: 5f 4c 30 44 00 70 0a 0d 5c 2f 03 5f 53 42 5f 50  _L0D.p..\/._SB_P
  0230: 43 49 30 50 54 38 30 86 5c 2f 03 5f 53 42 5f 50  CI0PT80.\/._SB_P
  0240: 43 49 30 45 55 53 42 0a 02 14 2e 5f 4c 31 38 00  CI0EUSB...._L18.
  0250: 70 0a 18 5c 2f 03 5f 53 42 5f 50 43 49 30 50 54  p..\/._SB_PCI0PT
  0260: 38 30 86 5c 2f 04 5f 53 42 5f 50 43 49 30 50 30  80.\/._SB_PCI0P0
  0270: 50 39 42 4d 46 33 0a 02 14 4d 04 5f 4c 31 45 00  P9BMF3...M._L1E.
  0280: 70 0a 1e 5c 2f 03 5f 53 42 5f 50 43 49 30 50 54  p..\/._SB_PCI0PT
  0290: 38 30 86 5c 2f 05 5f 53 42 5f 50 43 49 30 4c 50  80.\/._SB_PCI0LP
  02a0: 43 30 53 49 4f 5f 4b 42 43 30 0a 02 86 5c 2f 05  C0SIO_KBC0...\/.
  02b0: 5f 53 42 5f 50 43 49 30 4c 50 43 30 53 49 4f 5f  _SB_PCI0LPC0SIO_
  02c0: 4d 53 45 30 0a 02 10 4e 06 5f 50 52 5f 5b 83 0b  MSE0...N._PR_[..
  02d0: 43 50 55 30 00 10 10 00 00 06 5b 83 0b 43 50 55  CPU0......[..CPU
  02e0: 31 01 10 10 00 00 06 5b 83 0b 43 50 55 32 02 10  1......[..CPU2..
  02f0: 10 00 00 06 5b 83 0b 43 50 55 33 03 10 10 00 00  ....[..CPU3.....
  0300: 06 5b 83 0b 43 50 55 34 04 10 10 00 00 06 5b 83  .[..CPU4......[.
  0310: 0b 43 50 55 35 05 10 10 00 00 06 5b 83 0b 43 50  .CPU5......[..CP
  0320: 55 36 06 10 10 00 00 06 5b 83 0b 43 50 55 37 07  U6......[..CPU7.
  0330: 10 10 00 00 06 08 46 57 53 4f 0d 46 57 53 4f 00  ......FWSO.FWSO.
  0340: 08 5f 50 53 43 0a 00 14 4e 09 5f 50 53 30 00 70  ._PSC...N._PS0.p
  0350: 5f 50 53 43 60 70 0a 00 5f 50 53 43 a0 49 08 93  _PSC`p.._PSC.I..
  0360: 60 0a 03 70 0a 01 5c 2f 04 5f 53 42 5f 50 43 49  `..p..\/._SB_PCI
  0370: 30 4c 50 43 30 49 4e 46 5f a2 4c 06 5c 2f 04 5f  0LPC0INF_.L.\/._
  0380: 53 42 5f 50 43 49 30 4c 50 43 30 49 4e 46 5f 70  SB_PCI0LPC0INF_p
  0390: 0a 20 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43  . \/._SB_PCI0LPC
  03a0: 30 42 43 4d 44 70 00 5c 2f 04 5f 53 42 5f 50 43  0BCMDp.\/._SB_PC
  03b0: 49 30 4c 50 43 30 53 4d 49 43 a0 2b 90 93 5c 2f  I0LPC0SMIC.+..\/
  03c0: 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 49 4e 46  ._SB_PCI0LPC0INF
  03d0: 5f 0a 01 92 95 5c 2e 5f 53 42 5f 4f 53 54 42 0a  _....\._SB_OSTB.
  03e0: 04 5b 22 0b f4 01 14 0d 5f 50 53 33 00 70 0a 03  .["....._PS3.p..
  03f0: 5f 50 53 43 10 8e 26 04 5f 53 42 5f 5b 80 54 43  _PSC..&._SB_[.TC
  0400: 47 31 00 0c b5 1e f6 bf 0c 07 00 00 00 5b 81 29  G1...........[.)
  0410: 54 43 47 31 00 50 50 52 51 08 50 50 4c 4f 08 50  TCG1.PPRQ.PPLO.P
  0420: 50 52 50 08 50 50 4f 52 08 54 50 52 53 08 54 50  PRP.PPOR.TPRS.TP
  0430: 4d 56 08 4d 4f 52 5f 08 14 4a 08 50 48 53 52 09  MV.MOR_..J.PHSR.
  0440: 70 68 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43  ph\/._SB_PCI0LPC
  0450: 30 42 43 4d 44 70 00 5c 2f 04 5f 53 42 5f 50 43  0BCMDp.\/._SB_PC
  0460: 49 30 4c 50 43 30 44 49 44 5f 70 00 5c 2f 04 5f  I0LPC0DID_p.\/._
  0470: 53 42 5f 50 43 49 30 4c 50 43 30 53 4d 49 43 a0  SB_PCI0LPC0SMIC.
  0480: 16 93 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43  ..\/._SB_PCI0LPC
  0490: 30 42 43 4d 44 68 70 00 5c 2f 04 5f 53 42 5f 50  0BCMDhp.\/._SB_P
  04a0: 43 49 30 4c 50 43 30 42 43 4d 44 70 00 5c 2f 04  CI0LPC0BCMDp.\/.
  04b0: 5f 53 42 5f 50 43 49 30 4c 50 43 30 44 49 44 5f  _SB_PCI0LPC0DID_
  04c0: a4 0a 00 5b 82 4b 30 54 50 4d 5f 14 39 5f 48 49  ...[.K0TPM_.9_HI
  04d0: 44 00 a0 0e 93 54 50 4d 56 0a 01 a4 0c 24 d8 01  D....TPMV....$..
  04e0: 02 a0 0e 93 54 50 4d 56 0a 02 a4 0c 4d cf 35 04  ....TPMV....M.5.
  04f0: a0 0e 93 54 50 4d 56 0a 03 a4 0c 08 6d 01 01 a4  ...TPMV.....m...
  0500: 0c 41 d0 0c 31 08 5f 43 49 44 0c 41 d0 0c 31 08  .A..1._CID.A..1.
  0510: 5f 55 49 44 0a 01 14 12 5f 53 54 41 00 a0 08 54  _UID...._STA...T
  0520: 50 52 53 a4 0a 0f a4 0a 00 08 5f 43 52 53 11 11  PRS......._CRS..
  0530: 0a 0e 86 09 00 01 00 00 d4 fe 00 50 00 00 79 00  ...........P..y.
  0540: 14 3c 55 43 4d 50 02 a0 0a 92 93 0a 10 87 68 a4  .<UCMP........h.
  0550: 0a 00 a0 0a 92 93 0a 10 87 69 a4 0a 00 70 0a 00  .........i...p..
  0560: 60 a2 18 95 60 0a 10 a0 10 92 93 83 88 68 60 00  `...`........h`.
  0570: 83 88 69 60 00 a4 0a 00 75 60 a4 0a 01 14 42 25  ..i`....u`....B%
  0580: 5f 44 53 4d 0c a0 44 24 93 55 43 4d 50 68 11 13  _DSM..D$.UCMPh..
  0590: 0a 10 a6 fa dd 3d 1b 36 b4 4e a4 24 8d 10 08 9d  .....=.6.N.$....
  05a0: 16 53 0a 01 a0 0b 93 6a 0a 00 a4 11 04 0a 01 7f  .S.....j........
  05b0: a0 4f 04 93 6a 0a 01 a0 0f 93 87 6b 0a 00 a4 11  .O..j......k....
  05c0: 07 0a 04 31 2e 30 00 a0 1a 93 83 88 6b 0a 00 00  ...1.0......k...
  05d0: 0a 00 70 0a 00 5c 2e 5f 53 42 5f 4d 4f 52 5f a4  ..p..\._SB_MOR_.
  05e0: 0a 00 a0 1a 93 83 88 6b 0a 00 00 0a 01 70 0a 01  .......k.....p..
  05f0: 5c 2e 5f 53 42 5f 4d 4f 52 5f a4 0a 00 a4 0a 01  \._SB_MOR_......
  0600: a0 4e 14 93 6a 0a 02 a0 44 14 54 50 52 53 a0 14  .N..j...D.TPRS..
  0610: 93 83 88 6b 0a 00 00 0a 00 70 0a 00 50 50 52 51  ...k.....p..PPRQ
  0620: a4 0a 00 a0 14 93 83 88 6b 0a 00 00 0a 01 70 0a  ........k.....p.
  0630: 01 50 50 52 51 a4 0a 00 a0 14 93 83 88 6b 0a 00  .PPRQ........k..
  0640: 00 0a 02 70 0a 02 50 50 52 51 a4 0a 00 a0 14 93  ...p..PPRQ......
  0650: 83 88 6b 0a 00 00 0a 03 70 0a 03 50 50 52 51 a4  ..k.....p..PPRQ.
  0660: 0a 00 a0 14 93 83 88 6b 0a 00 00 0a 04 70 0a 04  .......k.....p..
  0670: 50 50 52 51 a4 0a 00 a0 14 93 83 88 6b 0a 00 00  PPRQ........k...
  0680: 0a 05 70 0a 05 50 50 52 51 a4 0a 00 a0 14 93 83  ..p..PPRQ.......
  0690: 88 6b 0a 00 00 0a 06 70 0a 06 50 50 52 51 a4 0a  .k.....p..PPRQ..
  06a0: 00 a0 14 93 83 88 6b 0a 00 00 0a 07 70 0a 07 50  ......k.....p..P
  06b0: 50 52 51 a4 0a 00 a0 14 93 83 88 6b 0a 00 00 0a  PRQ........k....
  06c0: 08 70 0a 08 50 50 52 51 a4 0a 00 a0 14 93 83 88  .p..PPRQ........
  06d0: 6b 0a 00 00 0a 09 70 0a 09 50 50 52 51 a4 0a 00  k.....p..PPRQ...
  06e0: a0 14 93 83 88 6b 0a 00 00 0a 0a 70 0a 0a 50 50  .....k.....p..PP
  06f0: 52 51 a4 0a 00 a0 14 93 83 88 6b 0a 00 00 0a 0b  RQ........k.....
  0700: 70 0a 0b 50 50 52 51 a4 0a 00 a0 14 93 83 88 6b  p..PPRQ........k
  0710: 0a 00 00 0a 0c 70 0a 00 50 50 52 51 a4 0a 01 a0  .....p..PPRQ....
  0720: 14 93 83 88 6b 0a 00 00 0a 0d 70 0a 00 50 50 52  ....k.....p..PPR
  0730: 51 a4 0a 01 a0 14 93 83 88 6b 0a 00 00 0a 0e 70  Q........k.....p
  0740: 0a 0e 50 50 52 51 a4 0a 00 a4 0a 01 a4 0a 01 a0  ..PPRQ..........
  0750: 20 93 6a 0a 03 a0 12 93 50 50 52 50 0a 00 a4 12   .j.....PPRP....
  0760: 08 02 0a 00 50 50 52 51 a4 12 06 02 0a 01 0a 00  ....PPRQ........
  0770: a0 08 93 6a 0a 04 a4 0a 01 a0 39 93 6a 0a 05 a0  ...j......9.j...
  0780: 29 93 50 50 52 50 0a 00 a0 14 50 50 4f 52 a4 12  ).PPRP....PPOR..
  0790: 0d 03 0a 00 50 50 4c 4f 0c f0 ff ff ff a4 12 0a  ....PPLO........
  07a0: 03 0a 00 50 50 4c 4f 0a 00 a4 12 08 03 0a 01 0a  ...PPLO.........
  07b0: 00 0a 00 a0 13 93 6a 0a 06 a0 0a 93 6b 0d 45 4e  ......j.....k.EN
  07c0: 00 a4 0a 00 a4 0a 01 a4 0a 01 a4 11 04 0a 01 00  ................
  07d0: 08 4f 53 54 42 0c ff ff ff ff 14 40 18 4f 53 54  .OSTB......@.OST
  07e0: 50 00 a0 42 17 93 5e 4f 53 54 42 0c ff ff ff ff  P..B..^OSTB.....
  07f0: a0 4f 0a 5b 12 5c 5f 4f 53 49 60 70 0a 00 5e 4f  .O.[.\_OSI`p..^O
  0800: 53 54 42 a0 1c 5c 5f 4f 53 49 0d 57 69 6e 64 6f  STB..\_OSI.Windo
  0810: 77 73 20 32 30 30 31 00 70 0a 08 5e 4f 53 54 42  ws 2001.p..^OSTB
  0820: a0 20 5c 5f 4f 53 49 0d 57 69 6e 64 6f 77 73 20  . \_OSI.Windows
  0830: 32 30 30 31 20 53 50 32 00 70 0a 08 5e 4f 53 54  2001 SP2.p..^OST
  0840: 42 a0 1e 5c 5f 4f 53 49 0d 57 69 6e 64 6f 77 73  B..\_OSI.Windows
  0850: 20 32 30 30 31 2e 31 00 70 0a 08 5e 4f 53 54 42   2001.1.p..^OSTB
  0860: a0 22 5c 5f 4f 53 49 0d 57 69 6e 64 6f 77 73 20  ."\_OSI.Windows
  0870: 32 30 30 31 2e 31 20 53 50 31 00 70 0a 08 5e 4f  2001.1 SP1.p..^O
  0880: 53 54 42 a0 1c 5c 5f 4f 53 49 0d 57 69 6e 64 6f  STB..\_OSI.Windo
  0890: 77 73 20 32 30 30 36 00 70 0a 08 5e 4f 53 54 42  ws 2006.p..^OSTB
  08a0: a1 44 0b a0 47 0a 5b 12 5c 5f 4f 53 5f 60 a0 26  .D..G.[.\_OS_`.&
  08b0: 5e 53 45 51 4c 5c 5f 4f 53 5f 0d 4d 69 63 72 6f  ^SEQL\_OS_.Micro
  08c0: 73 6f 66 74 20 57 69 6e 64 6f 77 73 00 70 0a 01  soft Windows.p..
  08d0: 5e 4f 53 54 42 a1 45 07 a0 3c 5e 53 45 51 4c 5c  ^OSTB.E..<^SEQL\
  08e0: 5f 4f 53 5f 0d 4d 69 63 72 6f 73 6f 66 74 20 57  _OS_.Microsoft W
  08f0: 69 6e 64 6f 77 73 4d 45 3a 20 4d 69 6c 6c 65 6e  indowsME: Millen
  0900: 6e 69 75 6d 20 45 64 69 74 69 6f 6e 00 70 0a 02  nium Edition.p..
  0910: 5e 4f 53 54 42 a1 35 a0 29 5e 53 45 51 4c 5c 5f  ^OSTB.5.)^SEQL\_
  0920: 4f 53 5f 0d 4d 69 63 72 6f 73 6f 66 74 20 57 69  OS_.Microsoft Wi
  0930: 6e 64 6f 77 73 20 4e 54 00 70 0a 04 5e 4f 53 54  ndows NT.p..^OST
  0940: 42 a1 09 70 0a 00 5e 4f 53 54 42 a1 09 70 0a 00  B..p..^OSTB..p..
  0950: 5e 4f 53 54 42 a4 5e 4f 53 54 42 14 4c 05 53 45  ^OSTB.^OSTB.L.SE
  0960: 51 4c 0a a3 70 87 68 60 70 87 69 61 a0 07 92 93  QL..p.h`p.ia....
  0970: 60 61 a4 00 08 42 55 46 30 11 02 60 70 68 42 55  `a...BUF0..`phBU
  0980: 46 30 08 42 55 46 31 11 02 60 70 69 42 55 46 31  F0.BUF1..`piBUF1
  0990: 70 00 62 a2 22 95 62 60 70 83 88 42 55 46 30 62  p.b.".b`p..BUF0b
  09a0: 00 63 70 83 88 42 55 46 31 62 00 64 a0 07 92 93  .cp..BUF1b.d....
  09b0: 63 64 a4 00 75 62 a4 01 14 4d 06 5f 4f 53 43 04  cd..ub...M._OSC.
  09c0: a0 45 06 93 68 11 13 0a 10 0c 5e 85 ed 90 6c bf  .E..h.....^...l.
  09d0: 47 a6 2a 26 de 0f c5 ad 5c 8a 6b 0a 00 43 44 57  G.*&....\.k..CDW
  09e0: 31 8a 6b 0a 04 43 44 57 32 8a 6b 0a 08 43 44 57  1.k..CDW2.k..CDW
  09f0: 33 08 53 55 50 50 0a 00 08 43 54 52 4c 0a 00 70  3.SUPP...CTRL..p
  0a00: 43 44 57 32 53 55 50 50 70 43 44 57 33 43 54 52  CDW2SUPPpCDW3CTR
  0a10: 4c a0 0b 7b 53 55 50 50 0a 01 00 a4 6b a4 7d 53  L..{SUPP....k.}S
  0a20: 55 50 50 0a 04 00 5b 82 8b c3 03 50 43 49 30 08  UPP...[....PCI0.
  0a30: 5f 48 49 44 0c 41 d0 0a 03 08 5f 42 42 4e 0a 00  _HID.A...._BBN..
  0a40: 08 5f 41 44 52 0a 00 08 52 53 52 43 11 4c 1b 0b  ._ADR...RSRC.L..
  0a50: b7 01 88 0e 00 02 0c 00 00 00 00 00 ff 00 00 00  ................
  0a60: 00 01 00 88 0e 00 01 0c 03 00 00 00 00 f7 0c 00  ................
  0a70: 00 f8 0c 00 47 01 f8 0c f8 0c 01 08 88 0e 00 01  ....G...........
  0a80: 0c 03 00 00 00 0d ff ff 00 00 00 f3 00 87 18 00  ................
  0a90: 00 0c 03 00 00 00 00 00 00 0a 00 ff ff 0b 00 00  ................
  0aa0: 00 00 00 00 00 02 00 00 87 18 00 00 0c 03 00 00  ................
  0ab0: 00 00 00 00 0c 00 ff 3f 0c 00 00 00 00 00 00 40  .......?.......@
  0ac0: 00 00 00 87 18 00 00 0c 03 00 00 00 00 00 40 0c  ..............@.
  0ad0: 00 ff 7f 0c 00 00 00 00 00 00 40 00 00 00 87 18  ..........@.....
  0ae0: 00 00 0c 03 00 00 00 00 00 80 0c 00 ff bf 0c 00  ................
  0af0: 00 00 00 00 00 40 00 00 00 87 18 00 00 0c 03 00  .....@..........
  0b00: 00 00 00 00 c0 0c 00 ff ff 0c 00 00 00 00 00 00  ................
  0b10: 40 00 00 00 87 18 00 00 0c 03 00 00 00 00 00 00  @...............
  0b20: 0d 00 ff 3f 0d 00 00 00 00 00 00 40 00 00 00 87  ...?.......@....
  0b30: 18 00 00 0c 03 00 00 00 00 00 40 0d 00 ff 7f 0d  ..........@.....
  0b40: 00 00 00 00 00 00 40 00 00 00 87 18 00 00 0c 03  ......@.........
  0b50: 00 00 00 00 00 80 0d 00 ff bf 0d 00 00 00 00 00  ................
  0b60: 00 40 00 00 00 87 18 00 00 0c 03 00 00 00 00 00  .@..............
  0b70: c0 0d 00 ff ff 0d 00 00 00 00 00 00 40 00 00 00  ............@...
  0b80: 87 18 00 00 0c 03 00 00 00 00 00 00 0e 00 ff 3f  ...............?
  0b90: 0e 00 00 00 00 00 00 40 00 00 00 87 18 00 00 0c  .......@........
  0ba0: 03 00 00 00 00 00 40 0e 00 ff 7f 0e 00 00 00 00  ......@.........
  0bb0: 00 00 40 00 00 00 87 18 00 00 0c 03 00 00 00 00  ..@.............
  0bc0: 00 80 0e 00 ff bf 0e 00 00 00 00 00 00 40 00 00  .............@..
  0bd0: 00 87 18 00 00 0c 03 00 00 00 00 00 c0 0e 00 ff  ................
  0be0: ff 0e 00 00 00 00 00 00 40 00 00 00 87 18 00 00  ........@.......
  0bf0: 0c 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0c00: 00 00 00 00 00 00 00 79 00 14 46 4e 5f 43 52 53  .......y..FN_CRS
  0c10: 08 8a 52 53 52 43 0b a4 01 42 54 4d 4e 8a 52 53  ..RSRC...BTMN.RS
  0c20: 52 43 0b a8 01 42 54 4d 58 8a 52 53 52 43 0b b0  RC...BTMX.RSRC..
  0c30: 01 42 54 4c 4e 7b 54 4f 4c 4d 0b 00 f0 60 79 60  .BTLN{TOLM...`y`
  0c40: 0a 10 60 70 60 42 54 4d 4e 74 0c 00 00 c0 fe 60  ..`p`BTMNt.....`
  0c50: 42 54 4c 4e 74 72 42 54 4d 4e 42 54 4c 4e 00 0a  BTLNtrBTMNBTLN..
  0c60: 01 42 54 4d 58 8d 52 53 52 43 0b d8 02 43 30 52  .BTMX.RSRC...C0R
  0c70: 57 8a 52 53 52 43 0a 60 43 30 4d 4e 8a 52 53 52  W.RSRC.`C0MN.RSR
  0c80: 43 0a 64 43 30 4d 58 8a 52 53 52 43 0a 6c 43 30  C.dC0MX.RSRC.lC0
  0c90: 4c 4e 70 01 43 30 52 57 a0 12 93 7b 50 41 4d 31  LNp.C0RW...{PAM1
  0ca0: 0a 03 00 0a 01 70 00 43 30 52 57 70 00 43 30 4c  .....p.C0RWp.C0L
  0cb0: 4e a0 12 92 7b 50 41 4d 31 0a 03 00 70 0b 00 40  N...{PAM1...p..@
  0cc0: 43 30 4c 4e 8d 52 53 52 43 0b b0 03 43 34 52 57  C0LN.RSRC...C4RW
  0cd0: 8a 52 53 52 43 0a 7b 43 34 4d 4e 8a 52 53 52 43  .RSRC.{C4MN.RSRC
  0ce0: 0a 7f 43 34 4d 58 8a 52 53 52 43 0a 87 43 34 4c  ..C4MX.RSRC..C4L
  0cf0: 4e 70 01 43 34 52 57 a0 12 93 7b 50 41 4d 31 0a  Np.C4RW...{PAM1.
  0d00: 30 00 0a 10 70 00 43 34 52 57 70 00 43 34 4c 4e  0...p.C4RWp.C4LN
  0d10: a0 12 92 7b 50 41 4d 31 0a 30 00 70 0b 00 40 43  ...{PAM1.0.p..@C
  0d20: 34 4c 4e 8d 52 53 52 43 0b 88 04 43 38 52 57 8a  4LN.RSRC...C8RW.
  0d30: 52 53 52 43 0a 96 43 38 4d 4e 8a 52 53 52 43 0a  RSRC..C8MN.RSRC.
  0d40: 9a 43 38 4d 58 8a 52 53 52 43 0a a2 43 38 4c 4e  .C8MX.RSRC..C8LN
  0d50: 70 01 43 38 52 57 a0 12 93 7b 50 41 4d 32 0a 03  p.C8RW...{PAM2..
  0d60: 00 0a 01 70 00 43 38 52 57 70 00 43 38 4c 4e a0  ...p.C8RWp.C8LN.
  0d70: 12 92 7b 50 41 4d 32 0a 03 00 70 0b 00 40 43 38  ..{PAM2...p..@C8
  0d80: 4c 4e 8d 52 53 52 43 0b 60 05 43 43 52 57 8a 52  LN.RSRC.`.CCRW.R
  0d90: 53 52 43 0a b1 43 43 4d 4e 8a 52 53 52 43 0a b5  SRC..CCMN.RSRC..
  0da0: 43 43 4d 58 8a 52 53 52 43 0a bd 43 43 4c 4e 70  CCMX.RSRC..CCLNp
  0db0: 01 43 43 52 57 a0 12 93 7b 50 41 4d 32 0a 30 00  .CCRW...{PAM2.0.
  0dc0: 0a 10 70 00 43 43 52 57 70 00 43 43 4c 4e a0 12  ..p.CCRWp.CCLN..
  0dd0: 92 7b 50 41 4d 32 0a 30 00 70 0b 00 40 43 43 4c  .{PAM2.0.p..@CCL
  0de0: 4e 8d 52 53 52 43 0b 38 06 44 30 52 57 8a 52 53  N.RSRC.8.D0RW.RS
  0df0: 52 43 0a cc 44 30 4d 4e 8a 52 53 52 43 0a d0 44  RC..D0MN.RSRC..D
  0e00: 30 4d 58 8a 52 53 52 43 0a d8 44 30 4c 4e 70 01  0MX.RSRC..D0LNp.
  0e10: 44 30 52 57 a0 12 93 7b 50 41 4d 33 0a 03 00 0a  D0RW...{PAM3....
  0e20: 01 70 00 44 30 52 57 70 00 44 30 4c 4e a0 12 92  .p.D0RWp.D0LN...
  0e30: 7b 50 41 4d 33 0a 03 00 70 0b 00 40 44 30 4c 4e  {PAM3...p..@D0LN
  0e40: 8d 52 53 52 43 0b 10 07 44 34 52 57 8a 52 53 52  .RSRC...D4RW.RSR
  0e50: 43 0a e7 44 34 4d 4e 8a 52 53 52 43 0a eb 44 34  C..D4MN.RSRC..D4
  0e60: 4d 58 8a 52 53 52 43 0a f3 44 34 4c 4e 70 01 44  MX.RSRC..D4LNp.D
  0e70: 34 52 57 a0 12 93 7b 50 41 4d 33 0a 30 00 0a 10  4RW...{PAM3.0...
  0e80: 70 00 44 34 52 57 70 00 44 34 4c 4e a0 12 92 7b  p.D4RWp.D4LN...{
  0e90: 50 41 4d 33 0a 30 00 70 0b 00 40 44 34 4c 4e 8d  PAM3.0.p..@D4LN.
  0ea0: 52 53 52 43 0b e8 07 44 38 52 57 8a 52 53 52 43  RSRC...D8RW.RSRC
  0eb0: 0b 02 01 44 38 4d 4e 8a 52 53 52 43 0b 06 01 44  ...D8MN.RSRC...D
  0ec0: 38 4d 58 8a 52 53 52 43 0b 0e 01 44 38 4c 4e 70  8MX.RSRC...D8LNp
  0ed0: 01 44 38 52 57 a0 12 93 7b 50 41 4d 34 0a 03 00  .D8RW...{PAM4...
  0ee0: 0a 01 70 00 44 38 52 57 70 00 44 38 4c 4e a0 12  ..p.D8RWp.D8LN..
  0ef0: 92 7b 50 41 4d 34 0a 03 00 70 0b 00 40 44 38 4c  .{PAM4...p..@D8L
  0f00: 4e 8d 52 53 52 43 0b c0 08 44 43 52 57 8a 52 53  N.RSRC...DCRW.RS
  0f10: 52 43 0b 1d 01 44 43 4d 4e 8a 52 53 52 43 0b 21  RC...DCMN.RSRC.!
  0f20: 01 44 43 4d 58 8a 52 53 52 43 0b 29 01 44 43 4c  .DCMX.RSRC.).DCL
  0f30: 4e 70 01 44 43 52 57 a0 12 93 7b 50 41 4d 34 0a  Np.DCRW...{PAM4.
  0f40: 30 00 0a 10 70 00 44 43 52 57 70 00 44 43 4c 4e  0...p.DCRWp.DCLN
  0f50: a0 12 92 7b 50 41 4d 34 0a 30 00 70 0b 00 40 44  ...{PAM4.0.p..@D
  0f60: 43 4c 4e 8d 52 53 52 43 0b 98 09 45 30 52 57 8a  CLN.RSRC...E0RW.
  0f70: 52 53 52 43 0b 38 01 45 30 4d 4e 8a 52 53 52 43  RSRC.8.E0MN.RSRC
  0f80: 0b 3c 01 45 30 4d 58 8a 52 53 52 43 0b 44 01 45  .<.E0MX.RSRC.D.E
  0f90: 30 4c 4e 70 01 45 30 52 57 a0 12 93 7b 50 41 4d  0LNp.E0RW...{PAM
  0fa0: 35 0a 03 00 0a 01 70 00 45 30 52 57 70 00 45 30  5.....p.E0RWp.E0
  0fb0: 4c 4e a0 12 92 7b 50 41 4d 35 0a 03 00 70 0b 00  LN...{PAM5...p..
  0fc0: 40 45 30 4c 4e 8d 52 53 52 43 0b 70 0a 45 34 52  @E0LN.RSRC.p.E4R
  0fd0: 57 8a 52 53 52 43 0b 53 01 45 34 4d 4e 8a 52 53  W.RSRC.S.E4MN.RS
  0fe0: 52 43 0b 57 01 45 34 4d 58 8a 52 53 52 43 0b 5f  RC.W.E4MX.RSRC._
  0ff0: 01 45 34 4c 4e 70 01 45 34 52 57 a0 12 93 7b 50  .E4LNp.E4RW...{P
  1000: 41 4d 35 0a 30 00 0a 10 70 00 45 34 52 57 70 00  AM5.0...p.E4RWp.
  1010: 45 34 4c 4e a0 12 92 7b 50 41 4d 35 0a 30 00 70  E4LN...{PAM5.0.p
  1020: 0b 00 40 45 34 4c 4e 8d 52 53 52 43 0b 48 0b 45  ..@E4LN.RSRC.H.E
  1030: 38 52 57 8a 52 53 52 43 0b 6e 01 45 38 4d 4e 8a  8RW.RSRC.n.E8MN.
  1040: 52 53 52 43 0b 72 01 45 38 4d 58 8a 52 53 52 43  RSRC.r.E8MX.RSRC
  1050: 0b 7a 01 45 38 4c 4e 70 01 45 38 52 57 a0 12 93  .z.E8LNp.E8RW...
  1060: 7b 50 41 4d 36 0a 03 00 0a 01 70 00 45 38 52 57  {PAM6.....p.E8RW
  1070: 70 00 45 38 4c 4e a0 12 92 7b 50 41 4d 36 0a 03  p.E8LN...{PAM6..
  1080: 00 70 0b 00 40 45 38 4c 4e 8d 52 53 52 43 0b 20  .p..@E8LN.RSRC.
  1090: 0c 45 43 52 57 8a 52 53 52 43 0b 89 01 45 43 4d  .ECRW.RSRC...ECM
  10a0: 4e 8a 52 53 52 43 0b 8d 01 45 43 4d 58 8a 52 53  N.RSRC...ECMX.RS
  10b0: 52 43 0b 95 01 45 43 4c 4e 70 01 45 43 52 57 a0  RC...ECLNp.ECRW.
  10c0: 12 93 7b 50 41 4d 36 0a 30 00 0a 10 70 00 45 43  ..{PAM6.0...p.EC
  10d0: 52 57 70 00 45 43 4c 4e a0 12 92 7b 50 41 4d 36  RWp.ECLN...{PAM6
  10e0: 0a 30 00 70 0b 00 40 45 43 4c 4e a4 52 53 52 43  .0.p..@ECLN.RSRC
  10f0: 14 10 5f 49 4e 49 00 5c 2e 5f 53 42 5f 4f 53 54  .._INI.\._SB_OST
  1100: 50 5b 82 4a 10 50 30 50 31 08 5f 41 44 52 0c 00  P[.J.P0P1._ADR..
  1110: 00 01 00 5b 80 50 43 45 31 02 0a 00 0a ff 5b 81  ...[.PCE1.....[.
  1120: 21 50 43 45 31 03 00 40 24 00 09 50 47 50 45 01  !PCE1..@$..PGPE.
  1130: 00 46 1f 00 03 50 4d 45 49 01 00 2c 50 4d 45 53  .F...PMEI..,PMES
  1140: 01 08 5f 50 52 57 12 06 02 0a 09 0a 05 14 4f 0b  .._PRW........O.
  1150: 5f 50 52 54 00 a0 41 08 92 5c 50 49 43 46 a4 12  _PRT..A..\PICF..
  1160: 47 07 04 12 1c 04 0b ff ff 0a 00 5c 2f 04 5f 53  G..........\/._S
  1170: 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 41 0a 00  B_PCI0LPC0LNKA..
  1180: 12 1c 04 0b ff ff 0a 01 5c 2f 04 5f 53 42 5f 50  ........\/._SB_P
  1190: 43 49 30 4c 50 43 30 4c 4e 4b 42 0a 00 12 1c 04  CI0LPC0LNKB.....
  11a0: 0b ff ff 0a 02 5c 2f 04 5f 53 42 5f 50 43 49 30  .....\/._SB_PCI0
  11b0: 4c 50 43 30 4c 4e 4b 43 0a 00 12 1c 04 0b ff ff  LPC0LNKC........
  11c0: 0a 03 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43  ..\/._SB_PCI0LPC
  11d0: 30 4c 4e 4b 44 0a 00 a1 35 a4 12 32 04 12 0b 04  0LNKD...5..2....
  11e0: 0b ff ff 0a 00 0a 00 0a 30 12 0b 04 0b ff ff 0a  ........0.......
  11f0: 01 0a 00 0a 3a 12 0b 04 0b ff ff 0a 02 0a 00 0a  ....:...........
  1200: 42 12 0b 04 0b ff ff 0a 03 0a 00 0a 3e 5b 82 4a  B...........>[.J
  1210: 10 50 30 50 35 08 5f 41 44 52 0c 00 00 05 00 5b  .P0P5._ADR.....[
  1220: 80 50 43 45 35 02 0a 00 0a ff 5b 81 21 50 43 45  .PCE5.....[.!PCE
  1230: 35 03 00 40 24 00 09 50 47 50 45 01 00 46 1f 00  5..@$..PGPE..F..
  1240: 03 50 4d 45 49 01 00 2c 50 4d 45 53 01 08 5f 50  .PMEI..,PMES.._P
  1250: 52 57 12 06 02 0a 09 0a 05 14 4f 0b 5f 50 52 54  RW........O._PRT
  1260: 00 a0 41 08 92 5c 50 49 43 46 a4 12 47 07 04 12  ..A..\PICF..G...
  1270: 1c 04 0b ff ff 0a 00 5c 2f 04 5f 53 42 5f 50 43  .......\/._SB_PC
  1280: 49 30 4c 50 43 30 4c 4e 4b 41 0a 00 12 1c 04 0b  I0LPC0LNKA......
  1290: ff ff 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30 4c  ....\/._SB_PCI0L
  12a0: 50 43 30 4c 4e 4b 42 0a 00 12 1c 04 0b ff ff 0a  PC0LNKB.........
  12b0: 02 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30  .\/._SB_PCI0LPC0
  12c0: 4c 4e 4b 43 0a 00 12 1c 04 0b ff ff 0a 03 5c 2f  LNKC..........\/
  12d0: 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b  ._SB_PCI0LPC0LNK
  12e0: 44 0a 00 a1 35 a4 12 32 04 12 0b 04 0b ff ff 0a  D...5..2........
  12f0: 00 0a 00 0a 34 12 0b 04 0b ff ff 0a 01 0a 00 0a  ....4...........
  1300: 3c 12 0b 04 0b ff ff 0a 02 0a 00 0a 44 12 0b 04  <...........D...
  1310: 0b ff ff 0a 03 0a 00 0a 40 5b 82 4f 34 50 30 50  ........@[.O4P0P
  1320: 39 08 5f 41 44 52 0c 00 00 09 00 5b 80 50 43 45  9._ADR.....[.PCE
  1330: 39 02 0a 00 0a ff 5b 81 21 50 43 45 39 13 00 40  9.....[.!PCE9..@
  1340: 24 00 09 50 47 50 45 01 00 46 1f 00 03 50 4d 45  $..PGPE..F...PME
  1350: 49 01 00 2c 50 4d 45 53 01 14 42 04 5f 50 52 54  I..,PMES..B._PRT
  1360: 00 a0 28 92 5c 50 49 43 46 a4 12 1f 01 12 1c 04  ..(.\PICF.......
  1370: 0b ff ff 0a 00 5c 2f 04 5f 53 42 5f 50 43 49 30  .....\/._SB_PCI0
  1380: 4c 50 43 30 4c 4e 4b 41 0a 00 a1 11 a4 12 0e 01  LPC0LNKA........
  1390: 12 0b 04 0b ff ff 0a 00 0a 00 0a 38 5b 82 4b 12  ...........8[.K.
  13a0: 42 4d 46 30 08 5f 41 44 52 0a 00 14 42 04 5f 50  BMF0._ADR...B._P
  13b0: 52 54 00 a0 28 92 5c 50 49 43 46 a4 12 1f 01 12  RT..(.\PICF.....
  13c0: 1c 04 0b ff ff 0a 00 5c 2f 04 5f 53 42 5f 50 43  .......\/._SB_PC
  13d0: 49 30 4c 50 43 30 4c 4e 4b 41 0a 00 a1 11 a4 12  I0LPC0LNKA......
  13e0: 0e 01 12 0b 04 0b ff ff 0a 00 0a 00 0a 38 5b 82  .............8[.
  13f0: 49 0d 42 50 44 30 08 5f 41 44 52 0a 00 08 5f 50  I.BPD0._ADR..._P
  1400: 52 57 12 06 02 0a 09 0a 05 14 4f 0b 5f 50 52 54  RW........O._PRT
  1410: 00 a0 41 08 92 5c 50 49 43 46 a4 12 47 07 04 12  ..A..\PICF..G...
  1420: 1c 04 0b ff ff 0a 00 5c 2f 04 5f 53 42 5f 50 43  .......\/._SB_PC
  1430: 49 30 4c 50 43 30 4c 4e 4b 41 0a 00 12 1c 04 0b  I0LPC0LNKA......
  1440: ff ff 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30 4c  ....\/._SB_PCI0L
  1450: 50 43 30 4c 4e 4b 42 0a 00 12 1c 04 0b ff ff 0a  PC0LNKB.........
  1460: 02 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30  .\/._SB_PCI0LPC0
  1470: 4c 4e 4b 43 0a 00 12 1c 04 0b ff ff 0a 03 5c 2f  LNKC..........\/
  1480: 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b  ._SB_PCI0LPC0LNK
  1490: 44 0a 00 a1 35 a4 12 32 04 12 0b 04 0b ff ff 0a  D...5..2........
  14a0: 00 0a 00 0a 38 12 0b 04 0b ff ff 0a 01 0a 00 0a  ....8...........
  14b0: 46 12 0b 04 0b ff ff 0a 02 0a 00 0a 47 12 0b 04  F...........G...
  14c0: 0b ff ff 0a 03 0a 00 0a 46 5b 82 4f 19 42 4d 46  ........F[.O.BMF
  14d0: 33 08 5f 41 44 52 0a 03 08 5f 50 52 57 12 06 02  3._ADR..._PRW...
  14e0: 0a 18 0a 05 14 45 18 5f 50 52 54 00 a0 45 10 92  .....E._PRT..E..
  14f0: 5c 50 49 43 46 a4 12 4b 0f 08 12 1e 04 0c ff ff  \PICF..K........
  1500: 01 00 0a 00 5c 2f 04 5f 53 42 5f 50 43 49 30 4c  ....\/._SB_PCI0L
  1510: 50 43 30 4c 4e 4b 41 0a 00 12 1e 04 0c ff ff 01  PC0LNKA.........
  1520: 00 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50  ...\/._SB_PCI0LP
  1530: 43 30 4c 4e 4b 42 0a 00 12 1e 04 0c ff ff 01 00  C0LNKB..........
  1540: 0a 02 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43  ..\/._SB_PCI0LPC
  1550: 30 4c 4e 4b 43 0a 00 12 1e 04 0c ff ff 01 00 0a  0LNKC...........
  1560: 03 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30  .\/._SB_PCI0LPC0
  1570: 4c 4e 4b 44 0a 00 12 1e 04 0c ff ff 02 00 0a 00  LNKD............
  1580: 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c  \/._SB_PCI0LPC0L
  1590: 4e 4b 42 0a 00 12 1e 04 0c ff ff 02 00 0a 01 5c  NKB............\
  15a0: 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e  /._SB_PCI0LPC0LN
  15b0: 4b 43 0a 00 12 1e 04 0c ff ff 02 00 0a 02 5c 2f  KC............\/
  15c0: 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b  ._SB_PCI0LPC0LNK
  15d0: 44 0a 00 12 1e 04 0c ff ff 02 00 0a 03 5c 2f 04  D............\/.
  15e0: 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 41  _SB_PCI0LPC0LNKA
  15f0: 0a 00 a1 47 07 a4 12 43 07 08 12 0d 04 0c ff ff  ...G...C........
  1600: 01 00 0a 00 0a 00 0a 18 12 0d 04 0c ff ff 01 00  ................
  1610: 0a 01 0a 00 0a 19 12 0d 04 0c ff ff 01 00 0a 02  ................
  1620: 0a 00 0a 1a 12 0d 04 0c ff ff 01 00 0a 03 0a 00  ................
  1630: 0a 1b 12 0d 04 0c ff ff 02 00 0a 00 0a 00 0a 19  ................
  1640: 12 0d 04 0c ff ff 02 00 0a 01 0a 00 0a 1a 12 0d  ................
  1650: 04 0c ff ff 02 00 0a 02 0a 00 0a 1b 12 0d 04 0c  ................
  1660: ff ff 02 00 0a 03 0a 00 0a 18 14 41 39 5f 50 52  ...........A9_PR
  1670: 54 00 a0 41 27 92 5c 50 49 43 46 a4 12 47 26 14  T..A'.\PICF..G&.
  1680: 12 1c 04 0b ff ff 0a 00 5c 2f 04 5f 53 42 5f 50  ........\/._SB_P
  1690: 43 49 30 4c 50 43 30 4c 4e 4b 41 0a 00 12 1c 04  CI0LPC0LNKA.....
  16a0: 0b ff ff 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30  .....\/._SB_PCI0
  16b0: 4c 50 43 30 4c 4e 4b 42 0a 00 12 1c 04 0b ff ff  LPC0LNKB........
  16c0: 0a 02 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43  ..\/._SB_PCI0LPC
  16d0: 30 4c 4e 4b 43 0a 00 12 1c 04 0b ff ff 0a 03 5c  0LNKC..........\
  16e0: 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e  /._SB_PCI0LPC0LN
  16f0: 4b 44 0a 00 12 1e 04 0c ff ff 01 00 0a 00 5c 2f  KD............\/
  1700: 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b  ._SB_PCI0LPC0LNK
  1710: 41 0a 00 12 1e 04 0c ff ff 05 00 0a 00 5c 2f 04  A............\/.
  1720: 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 41  _SB_PCI0LPC0LNKA
  1730: 0a 00 12 1e 04 0c ff ff 09 00 0a 00 5c 2f 04 5f  ............\/._
  1740: 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 41 0a  SB_PCI0LPC0LNKA.
  1750: 00 12 1e 04 0c ff ff 0f 00 0a 00 5c 2f 04 5f 53  ...........\/._S
  1760: 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 41 0a 00  B_PCI0LPC0LNKA..
  1770: 12 1e 04 0c ff ff 1b 00 0a 00 5c 2f 04 5f 53 42  ..........\/._SB
  1780: 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 45 0a 00 12  _PCI0LPC0LNKE...
  1790: 1e 04 0c ff ff 1c 00 0a 00 5c 2f 04 5f 53 42 5f  .........\/._SB_
  17a0: 50 43 49 30 4c 50 43 30 4c 4e 4b 41 0a 00 12 1e  PCI0LPC0LNKA....
  17b0: 04 0c ff ff 1d 00 0a 00 5c 2f 04 5f 53 42 5f 50  ........\/._SB_P
  17c0: 43 49 30 4c 50 43 30 4c 4e 4b 45 0a 00 12 1e 04  CI0LPC0LNKE.....
  17d0: 0c ff ff 1d 00 0a 01 5c 2f 04 5f 53 42 5f 50 43  .......\/._SB_PC
  17e0: 49 30 4c 50 43 30 4c 4e 4b 46 0a 00 12 1e 04 0c  I0LPC0LNKF......
  17f0: ff ff 1d 00 0a 02 5c 2f 04 5f 53 42 5f 50 43 49  ......\/._SB_PCI
  1800: 30 4c 50 43 30 4c 4e 4b 47 0a 00 12 1e 04 0c ff  0LPC0LNKG.......
  1810: ff 1d 00 0a 03 5c 2f 04 5f 53 42 5f 50 43 49 30  .....\/._SB_PCI0
  1820: 4c 50 43 30 4c 4e 4b 48 0a 00 12 1e 04 0c ff ff  LPC0LNKH........
  1830: 1e 00 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30 4c  ....\/._SB_PCI0L
  1840: 50 43 30 4c 4e 4b 42 0a 00 12 1e 04 0c ff ff 1e  PC0LNKB.........
  1850: 00 0a 02 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50  ...\/._SB_PCI0LP
  1860: 43 30 4c 4e 4b 43 0a 00 12 1e 04 0c ff ff 1f 00  C0LNKC..........
  1870: 0a 00 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43  ..\/._SB_PCI0LPC
  1880: 30 4c 4e 4b 41 0a 00 12 1e 04 0c ff ff 1f 00 0a  0LNKA...........
  1890: 01 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30  .\/._SB_PCI0LPC0
  18a0: 4c 4e 4b 42 0a 00 12 1e 04 0c ff ff 1f 00 0a 02  LNKB............
  18b0: 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c  \/._SB_PCI0LPC0L
  18c0: 4e 4b 43 0a 00 12 1e 04 0c ff ff 1f 00 0a 03 5c  NKC............\
  18d0: 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e  /._SB_PCI0LPC0LN
  18e0: 4b 44 0a 00 a1 47 11 a4 12 43 11 14 12 0b 04 0b  KD...G...C......
  18f0: ff ff 0a 00 0a 00 0a 10 12 0b 04 0b ff ff 0a 01  ................
  1900: 0a 00 0a 11 12 0b 04 0b ff ff 0a 02 0a 00 0a 12  ................
  1910: 12 0b 04 0b ff ff 0a 03 0a 00 0a 13 12 0d 04 0c  ................
  1920: ff ff 01 00 0a 00 0a 00 0a 30 12 0d 04 0c ff ff  .........0......
  1930: 05 00 0a 00 0a 00 0a 34 12 0d 04 0c ff ff 09 00  .......4........
  1940: 0a 00 0a 00 0a 38 12 0d 04 0c ff ff 0f 00 0a 00  .....8..........
  1950: 0a 00 0a 39 12 0d 04 0c ff ff 1b 00 0a 00 0a 00  ...9............
  1960: 0a 14 12 0d 04 0c ff ff 1c 00 0a 00 0a 00 0a 10  ................
  1970: 12 0d 04 0c ff ff 1d 00 0a 00 0a 00 0a 14 12 0d  ................
  1980: 04 0c ff ff 1d 00 0a 01 0a 00 0a 15 12 0d 04 0c  ................
  1990: ff ff 1d 00 0a 02 0a 00 0a 16 12 0d 04 0c ff ff  ................
  19a0: 1d 00 0a 03 0a 00 0a 17 12 0d 04 0c ff ff 1e 00  ................
  19b0: 0a 01 0a 00 0a 11 12 0d 04 0c ff ff 1e 00 0a 02  ................
  19c0: 0a 00 0a 12 12 0d 04 0c ff ff 1f 00 0a 00 0a 00  ................
  19d0: 0a 10 12 0d 04 0c ff ff 1f 00 0a 01 0a 00 0a 11  ................
  19e0: 12 0d 04 0c ff ff 1f 00 0a 02 0a 00 0a 12 12 0d  ................
  19f0: 04 0c ff ff 1f 00 0a 03 0a 00 0a 13 14 09 5f 53  .............._S
  1a00: 31 44 00 a4 0a 01 5b 80 44 42 38 30 01 0a 80 0a  1D....[.DB80....
  1a10: 01 5b 81 0b 44 42 38 30 01 50 54 38 30 08 5b 80  .[..DB80.PT80.[.
  1a20: 44 42 39 30 01 0a 90 0a 01 5b 81 0b 44 42 39 30  DB90.....[..DB90
  1a30: 01 50 54 39 30 08 5b 80 52 45 47 53 00 0c 59 00  .PT90.[.REGS..Y.
  1a40: 08 e0 0a 08 5b 81 29 52 45 47 53 00 50 41 4d 30  ....[.)REGS.PAM0
  1a50: 08 50 41 4d 31 08 50 41 4d 32 08 50 41 4d 33 08  .PAM1.PAM2.PAM3.
  1a60: 50 41 4d 34 08 50 41 4d 35 08 50 41 4d 36 08 5b  PAM4.PAM5.PAM6.[
  1a70: 80 4c 4d 45 4d 00 0c 6c 10 08 e0 0a 02 5b 81 0b  .LMEM..l.....[..
  1a80: 4c 4d 45 4d 00 54 4f 4c 4d 10 5b 82 1b 41 5a 4c  LMEM.TOLM.[..AZL
  1a90: 41 08 5f 41 44 52 0c 00 00 1b 00 08 5f 50 52 57  A._ADR......_PRW
  1aa0: 12 06 02 0a 05 0a 05 5b 82 4a 10 50 45 58 30 08  .......[.J.PEX0.
  1ab0: 5f 41 44 52 0c 00 00 1c 00 5b 80 50 43 45 45 02  _ADR.....[.PCEE.
  1ac0: 0a 00 0a ff 5b 81 21 50 43 45 45 03 00 40 31 50  ....[.!PCEE..@1P
  1ad0: 4d 45 53 01 00 4f 3b 00 0f 50 53 43 49 01 00 10  MES..O;..PSCI...
  1ae0: 00 0f 50 4d 53 53 01 08 5f 50 52 57 12 06 02 0a  ..PMSS.._PRW....
  1af0: 09 0a 05 14 4f 0b 5f 50 52 54 00 a0 41 08 92 5c  ....O._PRT..A..\
  1b00: 50 49 43 46 a4 12 47 07 04 12 1c 04 0b ff ff 0a  PICF..G.........
  1b10: 00 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30  .\/._SB_PCI0LPC0
  1b20: 4c 4e 4b 41 0a 00 12 1c 04 0b ff ff 0a 01 5c 2f  LNKA..........\/
  1b30: 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b  ._SB_PCI0LPC0LNK
  1b40: 42 0a 00 12 1c 04 0b ff ff 0a 02 5c 2f 04 5f 53  B..........\/._S
  1b50: 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 43 0a 00  B_PCI0LPC0LNKC..
  1b60: 12 1c 04 0b ff ff 0a 03 5c 2f 04 5f 53 42 5f 50  ........\/._SB_P
  1b70: 43 49 30 4c 50 43 30 4c 4e 4b 44 0a 00 a1 35 a4  CI0LPC0LNKD...5.
  1b80: 12 32 04 12 0b 04 0b ff ff 0a 00 0a 00 0a 10 12  .2..............
  1b90: 0b 04 0b ff ff 0a 01 0a 00 0a 11 12 0b 04 0b ff  ................
  1ba0: ff 0a 02 0a 00 0a 12 12 0b 04 0b ff ff 0a 03 0a  ................
  1bb0: 00 0a 13 5b 82 4c 06 55 53 42 31 08 5f 41 44 52  ...[.L.USB1._ADR
  1bc0: 0c 00 00 1d 00 5b 80 55 53 31 57 02 0a c4 0a 04  .....[.US1W.....
  1bd0: 5b 81 0b 55 53 31 57 13 57 31 45 4e 02 08 5f 50  [..US1W.W1EN.._P
  1be0: 52 57 12 06 02 0a 03 0a 05 14 19 5f 50 53 57 01  RW........._PSW.
  1bf0: a0 09 68 70 0a 03 57 31 45 4e a1 08 70 0a 00 57  ..hp..W1EN..p..W
  1c00: 31 45 4e 14 09 5f 53 31 44 00 a4 0a 01 14 09 5f  1EN.._S1D......_
  1c10: 53 33 44 00 a4 0a 02 14 09 5f 53 34 44 00 a4 0a  S3D......_S4D...
  1c20: 02 5b 82 4c 06 55 53 42 32 08 5f 41 44 52 0c 01  .[.L.USB2._ADR..
  1c30: 00 1d 00 5b 80 55 53 32 57 02 0a c4 0a 04 5b 81  ...[.US2W.....[.
  1c40: 0b 55 53 32 57 13 57 32 45 4e 02 08 5f 50 52 57  .US2W.W2EN.._PRW
  1c50: 12 06 02 0a 04 0a 05 14 19 5f 50 53 57 01 a0 09  ........._PSW...
  1c60: 68 70 0a 03 57 32 45 4e a1 08 70 0a 00 57 32 45  hp..W2EN..p..W2E
  1c70: 4e 14 09 5f 53 31 44 00 a4 0a 01 14 09 5f 53 33  N.._S1D......_S3
  1c80: 44 00 a4 0a 02 14 09 5f 53 34 44 00 a4 0a 02 5b  D......_S4D....[
  1c90: 82 4c 06 55 53 42 33 08 5f 41 44 52 0c 02 00 1d  .L.USB3._ADR....
  1ca0: 00 5b 80 55 53 42 4f 02 0a c4 0a 04 5b 81 0b 55  .[.USBO.....[..U
  1cb0: 53 42 4f 13 52 53 45 4e 02 08 5f 50 52 57 12 06  SBO.RSEN.._PRW..
  1cc0: 02 0a 0c 0a 05 14 19 5f 50 53 57 01 a0 09 68 70  ......._PSW...hp
  1cd0: 0a 03 52 53 45 4e a1 08 70 0a 00 52 53 45 4e 14  ..RSEN..p..RSEN.
  1ce0: 09 5f 53 31 44 00 a4 0a 02 14 09 5f 53 33 44 00  ._S1D......_S3D.
  1cf0: a4 0a 02 14 09 5f 53 34 44 00 a4 0a 02 5b 82 4c  ....._S4D....[.L
  1d00: 06 55 53 42 34 08 5f 41 44 52 0c 03 00 1d 00 5b  .USB4._ADR.....[
  1d10: 80 55 53 42 4f 02 0a c4 0a 04 5b 81 0b 55 53 42  .USBO.....[..USB
  1d20: 4f 13 52 53 45 4e 02 08 5f 50 52 57 12 06 02 0a  O.RSEN.._PRW....
  1d30: 0e 0a 05 14 19 5f 50 53 57 01 a0 09 68 70 0a 03  ....._PSW...hp..
  1d40: 52 53 45 4e a1 08 70 0a 00 52 53 45 4e 14 09 5f  RSEN..p..RSEN.._
  1d50: 53 31 44 00 a4 0a 02 14 09 5f 53 33 44 00 a4 0a  S1D......_S3D...
  1d60: 02 14 09 5f 53 34 44 00 a4 0a 02 5b 82 30 45 55  ..._S4D....[.0EU
  1d70: 53 42 08 5f 41 44 52 0c 07 00 1d 00 08 5f 53 31  SB._ADR......_S1
  1d80: 44 0a 02 08 5f 53 33 44 0a 02 08 5f 53 34 44 0a  D..._S3D..._S4D.
  1d90: 02 08 5f 50 52 57 12 06 02 0a 0d 0a 05 5b 82 46  .._PRW.......[.F
  1da0: 25 50 43 49 42 08 5f 41 44 52 0c 00 00 1e 00 14  %PCIB._ADR......
  1db0: 49 23 5f 50 52 54 00 a0 41 18 92 5c 50 49 43 46  I#_PRT..A..\PICF
  1dc0: a4 12 47 17 0c 12 1e 04 0c ff ff 01 00 0a 00 5c  ..G............\
  1dd0: 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e  /._SB_PCI0LPC0LN
  1de0: 4b 42 0a 00 12 1e 04 0c ff ff 02 00 0a 00 5c 2f  KB............\/
  1df0: 04 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b  ._SB_PCI0LPC0LNK
  1e00: 41 0a 00 12 1e 04 0c ff ff 02 00 0a 01 5c 2f 04  A............\/.
  1e10: 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 42  _SB_PCI0LPC0LNKB
  1e20: 0a 00 12 1e 04 0c ff ff 03 00 0a 00 5c 2f 04 5f  ............\/._
  1e30: 53 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 43 0a  SB_PCI0LPC0LNKC.
  1e40: 00 12 1e 04 0c ff ff 03 00 0a 01 5c 2f 04 5f 53  ...........\/._S
  1e50: 42 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 44 0a 00  B_PCI0LPC0LNKD..
  1e60: 12 1e 04 0c ff ff 03 00 0a 02 5c 2f 04 5f 53 42  ..........\/._SB
  1e70: 5f 50 43 49 30 4c 50 43 30 4c 4e 4b 41 0a 00 12  _PCI0LPC0LNKA...
  1e80: 1e 04 0c ff ff 03 00 0a 03 5c 2f 04 5f 53 42 5f  .........\/._SB_
  1e90: 50 43 49 30 4c 50 43 30 4c 4e 4b 42 0a 00 12 1e  PCI0LPC0LNKB....
  1ea0: 04 0c ff ff 04 00 0a 00 5c 2f 04 5f 53 42 5f 50  ........\/._SB_P
  1eb0: 43 49 30 4c 50 43 30 4c 4e 4b 44 0a 00 12 1e 04  CI0LPC0LNKD.....
  1ec0: 0c ff ff 04 00 0a 01 5c 2f 04 5f 53 42 5f 50 43  .......\/._SB_PC
  1ed0: 49 30 4c 50 43 30 4c 4e 4b 41 0a 00 12 1e 04 0c  I0LPC0LNKA......
  1ee0: ff ff 04 00 0a 02 5c 2f 04 5f 53 42 5f 50 43 49  ......\/._SB_PCI
  1ef0: 30 4c 50 43 30 4c 4e 4b 42 0a 00 12 1e 04 0c ff  0LPC0LNKB.......
  1f00: ff 04 00 0a 03 5c 2f 04 5f 53 42 5f 50 43 49 30  .....\/._SB_PCI0
  1f10: 4c 50 43 30 4c 4e 4b 43 0a 00 12 1e 04 0c ff ff  LPC0LNKC........
  1f20: 08 00 0a 00 5c 2f 04 5f 53 42 5f 50 43 49 30 4c  ....\/._SB_PCI0L
  1f30: 50 43 30 4c 4e 4b 45 0a 00 a1 4f 0a a4 12 4b 0a  PC0LNKE...O...K.
  1f40: 0c 12 0d 04 0c ff ff 01 00 0a 00 0a 00 0a 11 12  ................
  1f50: 0d 04 0c ff ff 02 00 0a 00 0a 00 0a 10 12 0d 04  ................
  1f60: 0c ff ff 02 00 0a 01 0a 00 0a 11 12 0d 04 0c ff  ................
  1f70: ff 03 00 0a 00 0a 00 0a 12 12 0d 04 0c ff ff 03  ................
  1f80: 00 0a 01 0a 00 0a 13 12 0d 04 0c ff ff 03 00 0a  ................
  1f90: 02 0a 00 0a 10 12 0d 04 0c ff ff 03 00 0a 03 0a  ................
  1fa0: 00 0a 11 12 0d 04 0c ff ff 04 00 0a 00 0a 00 0a  ................
  1fb0: 13 12 0d 04 0c ff ff 04 00 0a 01 0a 00 0a 10 12  ................
  1fc0: 0d 04 0c ff ff 04 00 0a 02 0a 00 0a 11 12 0d 04  ................
  1fd0: 0c ff ff 04 00 0a 03 0a 00 0a 12 12 0d 04 0c ff  ................
  1fe0: ff 08 00 0a 00 0a 00 0a 14 08 5f 50 52 57 12 06  .........._PRW..
  1ff0: 02 0a 0b 0a 05 5b 82 83 db 01 4c 50 43 30 5b 80  .....[....LPC0[.
  2000: 41 43 42 5f 00 0c bc 1e f6 bf 0c 90 00 00 00 5b  ACB_...........[
  2010: 81 16 41 43 42 5f 00 42 43 4d 44 08 44 49 44 5f  ..ACB_.BCMD.DID_
  2020: 20 49 4e 46 4f 40 45 5b 81 10 41 43 42 5f 00 44   INFO@E[..ACB_.D
  2030: 4d 59 5f 28 49 4e 46 5f 08 5b 80 53 4d 49 42 01  MY_(INF_.[.SMIB.
  2040: 0c 00 fe 00 00 0a 02 5b 81 0b 53 4d 49 42 00 53  .......[..SMIB.S
  2050: 4d 49 43 08 08 5f 41 44 52 0c 00 00 1f 00 08 44  MIC.._ADR......D
  2060: 56 45 4e 0a 00 14 07 44 45 43 44 0c a3 5b 82 4e  VEN....DECD..[.N
  2070: 23 4d 42 52 44 08 5f 48 49 44 0c 41 d0 0c 02 08  #MBRD._HID.A....
  2080: 5f 55 49 44 0a 1f 08 52 53 52 43 11 43 16 0b 5e  _UID...RSRC.C..^
  2090: 01 47 01 10 00 10 00 01 10 47 01 24 00 24 00 01  .G.......G.$.$..
  20a0: 02 47 01 28 00 28 00 01 02 47 01 2c 00 2c 00 01  .G.(.(...G.,.,..
  20b0: 02 47 01 2e 00 2e 00 01 02 47 01 30 00 30 00 01  .G.......G.0.0..
  20c0: 02 47 01 34 00 34 00 01 02 47 01 38 00 38 00 01  .G.4.4...G.8.8..
  20d0: 02 47 01 3c 00 3c 00 01 02 47 01 4e 00 4e 00 01  .G.<.<...G.N.N..
  20e0: 02 47 01 50 00 50 00 01 04 47 01 63 00 63 00 01  .G.P.P...G.c.c..
  20f0: 01 47 01 65 00 65 00 01 01 47 01 67 00 67 00 01  .G.e.e...G.g.g..
  2100: 01 47 01 72 00 72 00 01 06 47 01 80 00 80 00 01  .G.r.r...G......
  2110: 01 47 01 90 00 90 00 01 10 47 01 a4 00 a4 00 01  .G.......G......
  2120: 02 47 01 a8 00 a8 00 01 02 47 01 ac 00 ac 00 01  .G.......G......
  2130: 02 47 01 b0 00 b0 00 01 06 47 01 b8 00 b8 00 01  .G.......G......
  2140: 02 47 01 bc 00 bc 00 01 02 47 01 95 02 95 02 01  .G.......G......
  2150: 02 47 01 d0 04 d0 04 01 02 47 01 00 08 00 08 01  .G.......G......
  2160: 10 47 01 a0 0c a3 0c 01 04 47 01 00 10 00 10 01  .G.......G......
  2170: 80 47 01 80 11 80 11 01 40 47 01 00 fe 00 fe 01  .G......@G......
  2180: 01 86 09 00 01 00 00 00 e0 00 00 00 10 86 09 00  ................
  2190: 01 00 00 e0 fe 00 00 01 00 86 09 00 01 00 80 c8  ................
  21a0: fe 00 10 00 00 86 09 00 01 00 90 c8 fe 00 10 00  ................
  21b0: 00 86 09 00 01 00 c0 d1 fe 00 40 00 00 86 09 00  ..........@.....
  21c0: 01 00 00 00 fe 00 00 02 00 86 09 00 01 00 00 60  ...............`
  21d0: fe 00 00 10 00 86 09 00 01 00 00 d2 fe 00 00 02  ................
  21e0: 00 86 09 00 01 00 50 d4 fe 00 b0 04 00 79 00 14  ......P......y..
  21f0: 4d 0b 5f 43 52 53 00 a0 39 5c 5f 4f 53 49 0d 57  M._CRS..9\_OSI.W
  2200: 69 6e 64 6f 77 73 20 32 30 30 36 00 8b 52 53 52  indows 2006..RSR
  2210: 43 0a d4 53 49 4d 41 8c 52 53 52 43 0a d7 53 49  C..SIMA.RSRC..SI
  2220: 4d 4c 70 0b a1 0c 53 49 4d 41 70 0a 02 53 49 4d  MLp...SIMAp..SIM
  2230: 4c 8b 52 53 52 43 0a da 50 4d 4d 4e 8b 52 53 52  L.RSRC..PMMN.RSR
  2240: 43 0a dc 50 4d 4d 58 7b 5e 5e 50 4d 42 41 0b 80  C..PMMX{^^PMBA..
  2250: ff 50 4d 4d 4e 70 50 4d 4d 4e 50 4d 4d 58 8b 52  .PMMNpPMMNPMMX.R
  2260: 53 52 43 0a e2 47 50 4d 4e 8b 52 53 52 43 0a e4  SRC..GPMN.RSRC..
  2270: 47 50 4d 58 7b 5e 5e 47 50 42 41 0b c0 ff 47 50  GPMX{^^GPBA...GP
  2280: 4d 4e 70 47 50 4d 4e 47 50 4d 58 a0 1c 92 54 50  MNpGPMNGPMX...TP
  2290: 52 53 8a 52 53 52 43 0b 4c 01 52 53 4c 4e 70 0c  RS.RSRC.L.RSLNp.
  22a0: 00 50 02 00 52 53 4c 4e a4 52 53 52 43 5b 82 3d  .P..RSLN.RSRC[.=
  22b0: 44 4d 41 43 08 5f 48 49 44 0c 41 d0 02 00 08 5f  DMAC._HID.A...._
  22c0: 43 52 53 11 28 0a 25 47 01 00 00 00 00 01 20 47  CRS.(.%G...... G
  22d0: 01 81 00 81 00 01 11 47 01 93 00 93 00 01 0d 47  .......G.......G
  22e0: 01 c0 00 c0 00 01 20 2a 10 01 79 00 5b 82 26 4d  ...... *..y.[.&M
  22f0: 41 54 48 08 5f 48 49 44 0c 41 d0 0c 04 08 5f 43  ATH._HID.A...._C
  2300: 52 53 11 11 0a 0e 47 01 f0 00 f0 00 01 0f 23 00  RS....G.......#.
  2310: 20 01 79 00 5b 82 2c 50 49 43 5f 08 5f 48 49 44   .y.[.,PIC_._HID
  2320: 0b 41 d0 08 5f 43 52 53 11 19 0a 16 47 01 20 00  .A.._CRS....G. .
  2330: 20 00 01 02 47 01 a0 00 a0 00 01 02 23 04 00 01   ...G.......#...
  2340: 79 00 5b 82 48 0a 48 50 45 54 08 5f 48 49 44 0c  y.[.H.HPET._HID.
  2350: 41 d0 01 03 08 42 55 46 30 11 17 0a 14 22 01 00  A....BUF0...."..
  2360: 22 00 01 86 09 00 00 00 00 d0 fe 00 04 00 00 79  "..............y
  2370: 00 14 22 5f 53 54 41 00 a0 18 92 95 5c 2e 5f 53  .."_STA.....\._S
  2380: 42 5f 4f 53 54 42 0a 08 a0 08 48 50 41 45 a4 0a  B_OSTB....HPAE..
  2390: 0f a4 0a 00 14 47 05 5f 43 52 53 08 a0 4a 04 48  .....G._CRS..J.H
  23a0: 50 41 45 8a 42 55 46 30 0a 0a 48 50 54 30 a0 12  PAE.BUF0..HPT0..
  23b0: 93 48 50 41 53 0a 01 70 0c 00 10 d0 fe 48 50 54  .HPAS..p.....HPT
  23c0: 30 a0 12 93 48 50 41 53 0a 02 70 0c 00 20 d0 fe  0...HPAS..p.. ..
  23d0: 48 50 54 30 a0 12 93 48 50 41 53 0a 03 70 0c 00  HPT0...HPAS..p..
  23e0: 30 d0 fe 48 50 54 30 a4 42 55 46 30 5b 82 41 06  0..HPT0.BUF0[.A.
  23f0: 52 54 43 5f 08 5f 48 49 44 0c 41 d0 0b 00 08 42  RTC_._HID.A....B
  2400: 55 46 30 11 0d 0a 0a 47 01 70 00 70 00 01 02 79  UF0....G.p.p...y
  2410: 00 08 42 55 46 31 11 11 0a 0e 47 01 70 00 70 00  ..BUF1....G.p.p.
  2420: 01 02 23 00 01 01 79 00 14 26 5f 43 52 53 08 a0  ..#...y..&_CRS..
  2430: 1a 92 95 5c 2e 5f 53 42 5f 4f 53 54 42 0a 08 a0  ...\._SB_OSTB...
  2440: 0a 48 50 41 45 a4 42 55 46 30 a4 42 55 46 31 5b  .HPAE.BUF0.BUF1[
  2450: 82 22 53 50 4b 52 08 5f 48 49 44 0c 41 d0 08 00  ."SPKR._HID.A...
  2460: 08 5f 43 52 53 11 0d 0a 0a 47 01 61 00 61 00 01  ._CRS....G.a.a..
  2470: 01 79 00 5b 82 41 07 54 49 4d 45 08 5f 48 49 44  .y.[.A.TIME._HID
  2480: 0c 41 d0 01 00 08 42 55 46 30 11 15 0a 12 47 01  .A....BUF0....G.
  2490: 40 00 40 00 01 04 47 01 50 00 50 00 10 04 79 00  @.@...G.P.P...y.
  24a0: 08 42 55 46 31 11 19 0a 16 47 01 40 00 40 00 01  .BUF1....G.@.@..
  24b0: 04 47 01 50 00 50 00 10 04 23 01 00 01 79 00 14  .G.P.P...#...y..
  24c0: 26 5f 43 52 53 08 a0 1a 92 95 5c 2e 5f 53 42 5f  &_CRS.....\._SB_
  24d0: 4f 53 54 42 0a 08 a0 0a 48 50 41 45 a4 42 55 46  OSTB....HPAE.BUF
  24e0: 30 a4 42 55 46 31 5b 82 4a 0a 4c 4e 4b 41 08 5f  0.BUF1[.J.LNKA._
  24f0: 48 49 44 0c 41 d0 0c 0f 08 5f 55 49 44 0a 01 08  HID.A...._UID...
  2500: 5f 50 52 53 11 09 0a 06 23 f8 cc 18 79 00 08 52  _PRS....#...y..R
  2510: 53 52 43 11 09 0a 06 23 00 00 18 79 00 14 11 5f  SRC....#...y..._
  2520: 44 49 53 00 7d 50 49 52 41 0a 80 50 49 52 41 14  DIS.}PIRA..PIRA.
  2530: 26 5f 43 52 53 00 8b 52 53 52 43 0a 01 49 52 51  &_CRS..RSRC..IRQ
  2540: 30 7b 50 49 52 41 0a 0f 60 79 0a 01 60 49 52 51  0{PIRA..`y..`IRQ
  2550: 30 a4 52 53 52 43 14 24 5f 53 52 53 01 8b 68 0a  0.RSRC.$_SRS..h.
  2560: 01 49 52 51 30 82 49 52 51 30 60 76 60 7d 60 7b  .IRQ0.IRQ0`v`}`{
  2570: 50 49 52 41 0a 70 00 50 49 52 41 14 16 5f 53 54  PIRA.p.PIRA.._ST
  2580: 41 00 a0 0c 7b 50 49 52 41 0a 80 00 a4 0a 09 a4  A...{PIRA.......
  2590: 0a 0b 5b 82 4a 0a 4c 4e 4b 42 08 5f 48 49 44 0c  ..[.J.LNKB._HID.
  25a0: 41 d0 0c 0f 08 5f 55 49 44 0a 02 08 5f 50 52 53  A...._UID..._PRS
  25b0: 11 09 0a 06 23 f8 cc 18 79 00 08 52 53 52 43 11  ....#...y..RSRC.
  25c0: 09 0a 06 23 00 00 18 79 00 14 11 5f 44 49 53 00  ...#...y..._DIS.
  25d0: 7d 50 49 52 42 0a 80 50 49 52 42 14 26 5f 43 52  }PIRB..PIRB.&_CR
  25e0: 53 00 8b 52 53 52 43 0a 01 49 52 51 30 7b 50 49  S..RSRC..IRQ0{PI
  25f0: 52 42 0a 0f 60 79 0a 01 60 49 52 51 30 a4 52 53  RB..`y..`IRQ0.RS
  2600: 52 43 14 24 5f 53 52 53 01 8b 68 0a 01 49 52 51  RC.$_SRS..h..IRQ
  2610: 30 82 49 52 51 30 60 76 60 7d 60 7b 50 49 52 42  0.IRQ0`v`}`{PIRB
  2620: 0a 70 00 50 49 52 42 14 16 5f 53 54 41 00 a0 0c  .p.PIRB.._STA...
  2630: 7b 50 49 52 42 0a 80 00 a4 0a 09 a4 0a 0b 5b 82  {PIRB.........[.
  2640: 4a 0a 4c 4e 4b 43 08 5f 48 49 44 0c 41 d0 0c 0f  J.LNKC._HID.A...
  2650: 08 5f 55 49 44 0a 03 08 5f 50 52 53 11 09 0a 06  ._UID..._PRS....
  2660: 23 f8 cc 18 79 00 08 52 53 52 43 11 09 0a 06 23  #...y..RSRC....#
  2670: 00 00 18 79 00 14 11 5f 44 49 53 00 7d 50 49 52  ...y..._DIS.}PIR
  2680: 43 0a 80 50 49 52 43 14 26 5f 43 52 53 00 8b 52  C..PIRC.&_CRS..R
  2690: 53 52 43 0a 01 49 52 51 30 7b 50 49 52 43 0a 0f  SRC..IRQ0{PIRC..
  26a0: 60 79 0a 01 60 49 52 51 30 a4 52 53 52 43 14 24  `y..`IRQ0.RSRC.$
  26b0: 5f 53 52 53 01 8b 68 0a 01 49 52 51 30 82 49 52  _SRS..h..IRQ0.IR
  26c0: 51 30 60 76 60 7d 60 7b 50 49 52 43 0a 70 00 50  Q0`v`}`{PIRC.p.P
  26d0: 49 52 43 14 16 5f 53 54 41 00 a0 0c 7b 50 49 52  IRC.._STA...{PIR
  26e0: 43 0a 80 00 a4 0a 09 a4 0a 0b 5b 82 4a 0a 4c 4e  C.........[.J.LN
  26f0: 4b 44 08 5f 48 49 44 0c 41 d0 0c 0f 08 5f 55 49  KD._HID.A...._UI
  2700: 44 0a 04 08 5f 50 52 53 11 09 0a 06 23 f8 cc 18  D..._PRS....#...
  2710: 79 00 08 52 53 52 43 11 09 0a 06 23 00 00 18 79  y..RSRC....#...y
  2720: 00 14 11 5f 44 49 53 00 7d 50 49 52 44 0a 80 50  ..._DIS.}PIRD..P
  2730: 49 52 44 14 26 5f 43 52 53 00 8b 52 53 52 43 0a  IRD.&_CRS..RSRC.
  2740: 01 49 52 51 30 7b 50 49 52 44 0a 0f 60 79 0a 01  .IRQ0{PIRD..`y..
  2750: 60 49 52 51 30 a4 52 53 52 43 14 24 5f 53 52 53  `IRQ0.RSRC.$_SRS
  2760: 01 8b 68 0a 01 49 52 51 30 82 49 52 51 30 60 76  ..h..IRQ0.IRQ0`v
  2770: 60 7d 60 7b 50 49 52 44 0a 70 00 50 49 52 44 14  `}`{PIRD.p.PIRD.
  2780: 16 5f 53 54 41 00 a0 0c 7b 50 49 52 44 0a 80 00  ._STA...{PIRD...
  2790: a4 0a 09 a4 0a 0b 5b 82 4a 0a 4c 4e 4b 45 08 5f  ......[.J.LNKE._
  27a0: 48 49 44 0c 41 d0 0c 0f 08 5f 55 49 44 0a 05 08  HID.A...._UID...
  27b0: 5f 50 52 53 11 09 0a 06 23 f8 cc 18 79 00 08 52  _PRS....#...y..R
  27c0: 53 52 43 11 09 0a 06 23 00 00 18 79 00 14 11 5f  SRC....#...y..._
  27d0: 44 49 53 00 7d 50 49 52 45 0a 80 50 49 52 45 14  DIS.}PIRE..PIRE.
  27e0: 26 5f 43 52 53 00 8b 52 53 52 43 0a 01 49 52 51  &_CRS..RSRC..IRQ
  27f0: 30 7b 50 49 52 45 0a 0f 60 79 0a 01 60 49 52 51  0{PIRE..`y..`IRQ
  2800: 30 a4 52 53 52 43 14 24 5f 53 52 53 01 8b 68 0a  0.RSRC.$_SRS..h.
  2810: 01 49 52 51 30 82 49 52 51 30 60 76 60 7d 60 7b  .IRQ0.IRQ0`v`}`{
  2820: 50 49 52 45 0a 70 00 50 49 52 45 14 16 5f 53 54  PIRE.p.PIRE.._ST
  2830: 41 00 a0 0c 7b 50 49 52 45 0a 80 00 a4 0a 09 a4  A...{PIRE.......
  2840: 0a 0b 5b 82 4a 0a 4c 4e 4b 46 08 5f 48 49 44 0c  ..[.J.LNKF._HID.
  2850: 41 d0 0c 0f 08 5f 55 49 44 0a 06 08 5f 50 52 53  A...._UID..._PRS
  2860: 11 09 0a 06 23 f0 cc 18 79 00 08 52 53 52 43 11  ....#...y..RSRC.
  2870: 09 0a 06 23 00 00 18 79 00 14 11 5f 44 49 53 00  ...#...y..._DIS.
  2880: 7d 50 49 52 46 0a 80 50 49 52 46 14 26 5f 43 52  }PIRF..PIRF.&_CR
  2890: 53 00 8b 52 53 52 43 0a 01 49 52 51 30 7b 50 49  S..RSRC..IRQ0{PI
  28a0: 52 46 0a 0f 60 79 0a 01 60 49 52 51 30 a4 52 53  RF..`y..`IRQ0.RS
  28b0: 52 43 14 24 5f 53 52 53 01 8b 68 0a 01 49 52 51  RC.$_SRS..h..IRQ
  28c0: 30 82 49 52 51 30 60 76 60 7d 60 7b 50 49 52 46  0.IRQ0`v`}`{PIRF
  28d0: 0a 70 00 50 49 52 46 14 16 5f 53 54 41 00 a0 0c  .p.PIRF.._STA...
  28e0: 7b 50 49 52 46 0a 80 00 a4 0a 09 a4 0a 0b 5b 82  {PIRF.........[.
  28f0: 4a 0a 4c 4e 4b 47 08 5f 48 49 44 0c 41 d0 0c 0f  J.LNKG._HID.A...
  2900: 08 5f 55 49 44 0a 07 08 5f 50 52 53 11 09 0a 06  ._UID..._PRS....
  2910: 23 f8 cc 18 79 00 08 52 53 52 43 11 09 0a 06 23  #...y..RSRC....#
  2920: 00 00 18 79 00 14 11 5f 44 49 53 00 7d 50 49 52  ...y..._DIS.}PIR
  2930: 47 0a 80 50 49 52 47 14 26 5f 43 52 53 00 8b 52  G..PIRG.&_CRS..R
  2940: 53 52 43 0a 01 49 52 51 30 7b 50 49 52 47 0a 0f  SRC..IRQ0{PIRG..
  2950: 60 79 0a 01 60 49 52 51 30 a4 52 53 52 43 14 24  `y..`IRQ0.RSRC.$
  2960: 5f 53 52 53 01 8b 68 0a 01 49 52 51 30 82 49 52  _SRS..h..IRQ0.IR
  2970: 51 30 60 76 60 7d 60 7b 50 49 52 47 0a 70 00 50  Q0`v`}`{PIRG.p.P
  2980: 49 52 47 14 16 5f 53 54 41 00 a0 0c 7b 50 49 52  IRG.._STA...{PIR
  2990: 47 0a 80 00 a4 0a 09 a4 0a 0b 5b 82 4a 0a 4c 4e  G.........[.J.LN
  29a0: 4b 48 08 5f 48 49 44 0c 41 d0 0c 0f 08 5f 55 49  KH._HID.A...._UI
  29b0: 44 0a 08 08 5f 50 52 53 11 09 0a 06 23 f0 cc 18  D..._PRS....#...
  29c0: 79 00 08 52 53 52 43 11 09 0a 06 23 00 00 18 79  y..RSRC....#...y
  29d0: 00 14 11 5f 44 49 53 00 7d 50 49 52 48 0a 80 50  ..._DIS.}PIRH..P
  29e0: 49 52 48 14 26 5f 43 52 53 00 8b 52 53 52 43 0a  IRH.&_CRS..RSRC.
  29f0: 01 49 52 51 30 7b 50 49 52 48 0a 0f 60 79 0a 01  .IRQ0{PIRH..`y..
  2a00: 60 49 52 51 30 a4 52 53 52 43 14 24 5f 53 52 53  `IRQ0.RSRC.$_SRS
  2a10: 01 8b 68 0a 01 49 52 51 30 82 49 52 51 30 60 76  ..h..IRQ0.IRQ0`v
  2a20: 60 7d 60 7b 50 49 52 48 0a 70 00 50 49 52 48 14  `}`{PIRH.p.PIRH.
  2a30: 16 5f 53 54 41 00 a0 0c 7b 50 49 52 48 0a 80 00  ._STA...{PIRH...
  2a40: a4 0a 09 a4 0a 0b 5b 80 50 49 52 58 02 0a 60 0a  ......[.PIRX..`.
  2a50: 04 5b 81 1d 50 49 52 58 13 01 01 00 50 49 52 41  .[..PIRX....PIRA
  2a60: 08 50 49 52 42 08 50 49 52 43 08 50 49 52 44 08  .PIRB.PIRC.PIRD.
  2a70: 5b 80 50 49 52 59 02 0a 68 0a 04 5b 81 1d 50 49  [.PIRY..h..[..PI
  2a80: 52 59 13 01 01 00 50 49 52 45 08 50 49 52 46 08  RY....PIRE.PIRF.
  2a90: 50 49 52 47 08 50 49 52 48 08 5b 80 52 45 47 53  PIRG.PIRH.[.REGS
  2aa0: 02 0a 40 0a 10 5b 81 12 52 45 47 53 13 50 4d 42  ..@..[..REGS.PMB
  2ab0: 41 10 00 30 47 50 42 41 10 5b 80 50 4d 52 47 02  A..0GPBA.[.PMRG.
  2ac0: 0a a0 0a 04 5b 81 0d 50 4d 52 47 13 00 0a 42 50  ....[..PMRG...BP
  2ad0: 45 45 01 5b 80 4c 49 4f 45 02 0a 80 0a 02 5b 81  EE.[.LIOE.....[.
  2ae0: 19 4c 49 4f 45 12 43 41 50 44 03 00 01 43 42 50  .LIOE.CAPD...CBP
  2af0: 44 03 00 01 4c 50 50 44 02 14 43 0b 49 4f 44 45  D...LPPD..C.IODE
  2b00: 02 a0 3d 93 68 0a 00 a0 0d 93 69 0b f8 03 70 0a  ..=.h.....i...p.
  2b10: 00 43 41 50 44 a0 0d 93 69 0b f8 02 70 0a 01 43  .CAPD...i...p..C
  2b20: 41 50 44 a0 0d 93 69 0b e8 03 70 0a 07 43 41 50  APD...i...p..CAP
  2b30: 44 a0 0d 93 69 0b e8 02 70 0a 05 43 41 50 44 a0  D...i...p..CAPD.
  2b40: 3d 93 68 0a 01 a0 0d 93 69 0b f8 03 70 0a 00 43  =.h.....i...p..C
  2b50: 42 50 44 a0 0d 93 69 0b f8 02 70 0a 01 43 42 50  BPD...i...p..CBP
  2b60: 44 a0 0d 93 69 0b e8 03 70 0a 07 43 42 50 44 a0  D...i...p..CBPD.
  2b70: 0d 93 69 0b e8 02 70 0a 05 43 42 50 44 a0 2f 93  ..i...p..CBPD./.
  2b80: 68 0a 02 a0 0d 93 69 0b 78 03 70 0a 00 4c 50 50  h.....i.x.p..LPP
  2b90: 44 a0 0d 93 69 0b 78 02 70 0a 01 4c 50 50 44 a0  D...i.x.p..LPPD.
  2ba0: 0d 93 69 0b bc 03 70 0a 02 4c 50 50 44 5b 82 26  ..i...p..LPPD[.&
  2bb0: 46 57 48 44 08 5f 48 49 44 0c 25 d4 08 00 08 5f  FWHD._HID.%...._
  2bc0: 43 52 53 11 11 0a 0e 86 09 00 00 00 00 00 ff 00  CRS.............
  2bd0: 00 00 01 79 00 5b 80 4c 50 38 34 02 0a 00 0a ff  ...y.[.LP84.....
  2be0: 5b 81 15 4c 50 38 34 01 00 40 42 47 31 45 4e 01  [..LP84..@BG1EN.
  2bf0: 00 06 47 31 42 41 09 5b 01 4d 54 58 30 00 14 34  ..G1BA.[.MTX0..4
  2c00: 4f 50 44 43 01 5b 23 4d 54 58 30 ff ff 70 68 60  OPDC.[#MTX0..ph`
  2c10: 7b 60 0b 80 ff 60 7a 60 0a 07 60 70 60 47 31 42  {`...`z`..`p`G1B
  2c20: 41 70 0a 01 47 31 45 4e 5b 22 0b f4 01 5b 27 4d  Ap..G1EN["...['M
  2c30: 54 58 30 14 26 43 4c 44 43 00 5b 23 4d 54 58 30  TX0.&CLDC.[#MTX0
  2c40: ff ff 70 00 47 31 42 41 70 0a 00 47 31 45 4e 5b  ..p.G1BAp..G1EN[
  2c50: 22 0b f4 01 5b 27 4d 54 58 30 5b 80 4c 50 49 4f  "...['MTX0[.LPIO
  2c60: 02 0a 80 0a 04 10 49 27 5c 00 5b 81 29 5c 2f 04  ......I'\.[.)\/.
  2c70: 5f 53 42 5f 50 43 49 30 4c 50 43 30 4c 50 49 4f  _SB_PCI0LPC0LPIO
  2c80: 01 55 41 49 4f 08 50 52 49 4f 08 4c 50 45 31 08  .UAIO.PRIO.LPE1.
  2c90: 4c 50 45 32 08 14 48 0b 53 54 44 4d 02 a0 48 05  LPE2..H.STDM..H.
  2ca0: 68 a0 10 93 69 0a 02 7d 4c 50 45 31 0a 01 4c 50  h...i..}LPE1..LP
  2cb0: 45 31 a0 10 93 69 0a 03 7d 4c 50 45 31 0a 02 4c  E1...i..}LPE1..L
  2cc0: 50 45 31 a0 10 93 69 0a 01 7d 4c 50 45 31 0a 04  PE1...i..}LPE1..
  2cd0: 4c 50 45 31 a0 10 93 69 0a 00 7d 4c 50 45 31 0a  LPE1...i..}LPE1.
  2ce0: 08 4c 50 45 31 a0 10 93 69 0a 04 7d 4c 50 45 31  .LPE1...i..}LPE1
  2cf0: 0a 03 4c 50 45 32 a1 47 05 a0 10 93 69 0a 02 7b  ..LPE2.G....i..{
  2d00: 4c 50 45 31 0a fe 4c 50 45 31 a0 10 93 69 0a 03  LPE1..LPE1...i..
  2d10: 7b 4c 50 45 31 0a fd 4c 50 45 31 a0 10 93 69 0a  {LPE1..LPE1...i.
  2d20: 01 7b 4c 50 45 31 0a fb 4c 50 45 31 a0 10 93 69  .{LPE1..LPE1...i
  2d30: 0a 00 7b 4c 50 45 31 0a f7 4c 50 45 31 a0 10 93  ..{LPE1..LPE1...
  2d40: 69 0a 04 7b 4c 50 45 32 0a fc 4c 50 45 32 14 40  i..{LPE2..LPE2.@
  2d50: 19 43 4b 49 4f 02 8b 68 0a 02 49 4f 41 44 a0 41  .CKIO..h..IOAD.A
  2d60: 06 93 69 0a 02 7d 4c 50 45 31 0a 01 4c 50 45 31  ..i..}LPE1..LPE1
  2d70: 7b 55 41 49 4f 0a f0 60 a0 11 93 49 4f 41 44 0b  {UAIO..`...IOAD.
  2d80: f8 03 7d 60 0a 00 55 41 49 4f a0 11 93 49 4f 41  ..}`..UAIO...IOA
  2d90: 44 0b f8 02 7d 60 0a 01 55 41 49 4f a0 11 93 49  D...}`..UAIO...I
  2da0: 4f 41 44 0b e8 02 7d 60 0a 05 55 41 49 4f a0 11  OAD...}`..UAIO..
  2db0: 93 49 4f 41 44 0b e8 03 7d 60 0a 07 55 41 49 4f  .IOAD...}`..UAIO
  2dc0: a0 41 06 93 69 0a 03 7d 4c 50 45 31 0a 02 4c 50  .A..i..}LPE1..LP
  2dd0: 45 31 7b 55 41 49 4f 0a 0f 60 a0 11 93 49 4f 41  E1{UAIO..`...IOA
  2de0: 44 0b f8 03 7d 60 0a 00 55 41 49 4f a0 11 93 49  D...}`..UAIO...I
  2df0: 4f 41 44 0b f8 02 7d 60 0a 10 55 41 49 4f a0 11  OAD...}`..UAIO..
  2e00: 93 49 4f 41 44 0b e8 02 7d 60 0a 50 55 41 49 4f  .IOAD...}`.PUAIO
  2e10: a0 11 93 49 4f 41 44 0b e8 03 7d 60 0a 70 55 41  ...IOAD...}`.pUA
  2e20: 49 4f a0 4f 04 93 69 0a 01 7d 4c 50 45 31 0a 04  IO.O..i..}LPE1..
  2e30: 4c 50 45 31 7b 50 52 49 4f 0a fc 60 a0 11 93 49  LPE1{PRIO..`...I
  2e40: 4f 41 44 0b 78 03 7d 60 0a 00 50 52 49 4f a0 11  OAD.x.}`..PRIO..
  2e50: 93 49 4f 41 44 0b 78 02 7d 60 0a 01 50 52 49 4f  .IOAD.x.}`..PRIO
  2e60: a0 11 93 49 4f 41 44 0b bc 03 7d 60 0a 02 50 52  ...IOAD...}`..PR
  2e70: 49 4f a0 3c 93 69 0a 00 7d 4c 50 45 31 0a 08 4c  IO.<.i..}LPE1..L
  2e80: 50 45 31 7b 50 52 49 4f 0a ef 60 a0 11 93 49 4f  PE1{PRIO..`...IO
  2e90: 41 44 0b f0 03 7d 60 0a 00 50 52 49 4f a0 11 93  AD...}`..PRIO...
  2ea0: 49 4f 41 44 0b 70 03 7d 60 0a 10 50 52 49 4f a0  IOAD.p.}`..PRIO.
  2eb0: 2f 93 69 0a 04 a0 14 93 49 4f 41 44 0b 01 02 7d  /.i.....IOAD...}
  2ec0: 4c 50 45 32 0a 01 4c 50 45 32 a0 14 93 49 4f 41  LPE2..LPE2...IOA
  2ed0: 44 0b 09 02 7d 4c 50 45 32 0a 02 4c 50 45 32 5b  D...}LPE2..LPE2[
  2ee0: 80 50 53 32 50 01 0a 64 0a 01 5b 81 0b 50 53 32  .PS2P..d..[..PS2
  2ef0: 50 01 50 53 32 43 08 5b 82 41 eb 53 49 4f 5f 08  P.PS2C.[.A.SIO_.
  2f00: 5f 48 49 44 0c 41 d0 0a 05 5b 01 57 36 32 37 00  _HID.A...[.W627.
  2f10: 5b 80 53 49 42 50 01 0a 2e 0a 02 5b 81 0b 53 49  [.SIBP.....[..SI
  2f20: 42 50 01 42 50 49 4f 08 5b 80 53 49 49 4f 01 0a  BP.BPIO.[.SIIO..
  2f30: 2e 0a 02 5b 81 10 53 49 49 4f 01 49 4e 44 58 08  ...[..SIIO.INDX.
  2f40: 44 41 54 41 08 5b 86 4a 07 49 4e 44 58 44 41 54  DATA.[.J.INDXDAT
  2f50: 41 01 00 38 4c 44 4e 5f 08 00 40 0d 50 4f 57 5f  A..8LDN_..@.POW_
  2f60: 08 00 48 06 41 43 54 5f 01 00 4f 17 49 4f 42 48  ..H.ACT_..O.IOBH
  2f70: 08 49 4f 42 4c 08 49 4f 32 48 08 49 4f 32 4c 08  .IOBL.IO2H.IO2L.
  2f80: 00 40 06 49 4e 54 5f 04 00 1c 44 4d 41 53 03 00  .@.INT_...DMAS..
  2f90: 4d 35 5a 30 30 30 08 00 18 5a 30 30 31 08 00 48  M5Z000...Z001..H
  2fa0: 05 4d 4f 44 45 03 00 05 00 03 49 52 4d 44 03 00  .MODE.....IRMD..
  2fb0: 0a 00 06 53 4c 45 44 02 00 08 00 06 50 4c 45 44  ...SLED.....PLED
  2fc0: 02 14 1a 43 46 47 5f 01 70 0a 87 42 50 49 4f 70  ...CFG_.p..BPIOp
  2fd0: 0a 87 42 50 49 4f 70 68 4c 44 4e 5f 14 0d 58 43  ..BPIOphLDN_..XC
  2fe0: 46 47 00 70 0a aa 42 50 49 4f 14 3e 53 54 41 5f  FG.p..BPIO.>STA_
  2ff0: 01 5b 23 57 36 32 37 00 50 43 46 47 5f 68 70 0a  .[#W627.PCFG_hp.
  3000: 00 61 a0 09 41 43 54 5f 70 0a 0f 61 a1 10 a0 0e  .a..ACT_p..a....
  3010: 91 49 4f 42 48 49 4f 42 4c 70 0a 0d 61 58 43 46  .IOBHIOBLp..aXCF
  3020: 47 5b 27 57 36 32 37 a4 61 14 2e 44 49 53 5f 01  G['W627.a..DIS_.
  3030: 5b 23 57 36 32 37 88 13 43 46 47 5f 68 70 0a 00  [#W627..CFG_hp..
  3040: 41 43 54 5f 58 43 46 47 5b 27 57 36 32 37 53 54  ACT_XCFG['W627ST
  3050: 44 4d 0a 00 68 a4 0a 00 14 2e 50 53 30 5f 01 5b  DM..h.....PS0_.[
  3060: 23 57 36 32 37 88 13 43 46 47 5f 68 70 0a 01 41  #W627..CFG_hp..A
  3070: 43 54 5f 58 43 46 47 5b 27 57 36 32 37 53 54 44  CT_XCFG['W627STD
  3080: 4d 0a 01 68 a4 0a 00 14 27 50 53 33 5f 01 5b 23  M..h....'PS3_.[#
  3090: 57 36 32 37 88 13 43 46 47 5f 68 70 0a 00 41 43  W627..CFG_hp..AC
  30a0: 54 5f 58 43 46 47 5b 27 57 36 32 37 a4 0a 00 5b  T_XCFG['W627...[
  30b0: 82 4d 07 4b 42 43 30 08 5f 48 49 44 0c 41 d0 03  .M.KBC0._HID.A..
  30c0: 03 08 5f 43 49 44 0c 41 d0 03 0b 08 5f 43 52 53  .._CID.A...._CRS
  30d0: 11 19 0a 16 47 01 60 00 60 00 01 01 47 01 64 00  ....G.`.`...G.d.
  30e0: 64 00 01 01 23 02 00 01 79 00 08 5f 50 52 57 12  d...#...y.._PRW.
  30f0: 06 02 0a 1e 0a 01 14 37 5f 50 53 57 01 5b 23 57  .......7_PSW.[#W
  3100: 36 32 37 88 13 43 46 47 5f 0a 0a 70 0a f6 49 4e  627..CFG_..p..IN
  3110: 44 58 7d 7b 44 41 54 41 0a ef 00 79 68 0a 04 00  DX}{DATA...yh...
  3120: 44 41 54 41 58 43 46 47 5b 27 57 36 32 37 5b 82  DATAXCFG['W627[.
  3130: 4d 06 4d 53 45 30 08 5f 48 49 44 0c 41 d0 0f 13  M.MSE0._HID.A...
  3140: 08 5f 43 49 44 0c 41 d0 0f 13 08 5f 43 52 53 11  ._CID.A...._CRS.
  3150: 09 0a 06 23 00 10 01 79 00 08 5f 50 52 57 12 06  ...#...y.._PRW..
  3160: 02 0a 1e 0a 01 14 37 5f 50 53 57 01 5b 23 57 36  ......7_PSW.[#W6
  3170: 32 37 88 13 43 46 47 5f 0a 0a 70 0a f6 49 4e 44  27..CFG_..p..IND
  3180: 58 7d 7b 44 41 54 41 0a df 00 79 68 0a 05 00 44  X}{DATA...yh...D
  3190: 41 54 41 58 43 46 47 5b 27 57 36 32 37 5b 82 4f  ATAXCFG['W627[.O
  31a0: 1d 43 4f 4d 31 08 5f 48 49 44 0c 41 d0 05 01 08  .COM1._HID.A....
  31b0: 5f 55 49 44 0a 01 14 10 5f 53 54 41 00 70 53 54  _UID...._STA.pST
  31c0: 41 5f 0a 02 61 a4 61 08 5f 50 52 57 12 06 02 0a  A_..a.a._PRW....
  31d0: 08 0a 05 14 0c 5f 44 49 53 00 44 49 53 5f 0a 02  ....._DIS.DIS_..
  31e0: 14 43 0a 5f 43 52 53 00 08 52 53 52 43 11 10 0a  .C._CRS..RSRC...
  31f0: 0d 47 01 00 00 00 00 08 08 22 00 00 79 00 8c 52  .G......."..y..R
  3200: 53 52 43 0a 02 49 4f 31 5f 8c 52 53 52 43 0a 03  SRC..IO1_.RSRC..
  3210: 49 4f 32 5f 8c 52 53 52 43 0a 04 49 4f 33 5f 8c  IO2_.RSRC..IO3_.
  3220: 52 53 52 43 0a 05 49 4f 34 5f 8b 52 53 52 43 0a  RSRC..IO4_.RSRC.
  3230: 09 49 52 51 56 5b 23 57 36 32 37 88 13 43 46 47  .IRQV[#W627..CFG
  3240: 5f 0a 02 70 49 4f 42 4c 49 4f 31 5f 70 49 4f 42  _..pIOBLIO1_pIOB
  3250: 48 49 4f 32 5f 70 49 4f 42 4c 49 4f 33 5f 70 49  HIO2_pIOBLIO3_pI
  3260: 4f 42 48 49 4f 34 5f 70 0a 01 60 79 60 49 4e 54  OBHIO4_p..`y`INT
  3270: 5f 49 52 51 56 58 43 46 47 5b 27 57 36 32 37 a4  _IRQVXCFG['W627.
  3280: 52 53 52 43 08 5f 50 52 53 11 44 07 0a 70 31 00  RSRC._PRS.D..p1.
  3290: 47 01 f8 03 f8 03 01 08 23 10 00 01 30 47 01 f8  G.......#...0G..
  32a0: 02 f8 02 01 08 23 08 00 01 30 47 01 e8 03 e8 03  .....#...0G.....
  32b0: 01 08 23 10 00 01 30 47 01 e8 02 e8 02 01 08 23  ..#...0G.......#
  32c0: 08 00 01 31 0a 47 01 f8 03 f8 03 01 08 23 08 00  ...1.G.......#..
  32d0: 01 31 0a 47 01 f8 02 f8 02 01 08 23 10 00 01 31  .1.G.......#...1
  32e0: 0a 47 01 e8 03 e8 03 01 08 23 08 00 01 31 0a 47  .G.......#...1.G
  32f0: 01 e8 02 e8 02 01 08 23 10 00 01 38 79 00 14 45  .......#...8y..E
  3300: 06 5f 53 52 53 01 8c 68 0a 02 49 4f 31 5f 8c 68  ._SRS..h..IO1_.h
  3310: 0a 03 49 4f 32 5f 8b 68 0a 09 49 52 51 56 5b 23  ..IO2_.h..IRQV[#
  3320: 57 36 32 37 88 13 43 46 47 5f 0a 02 70 49 4f 31  W627..CFG_..pIO1
  3330: 5f 49 4f 42 4c 70 49 4f 32 5f 49 4f 42 48 82 49  _IOBLpIO2_IOBH.I
  3340: 52 51 56 60 74 60 0a 01 49 4e 54 5f 70 0a 01 41  RQV`t`..INT_p..A
  3350: 43 54 5f 58 43 46 47 5b 27 57 36 32 37 43 4b 49  CT_XCFG['W627CKI
  3360: 4f 68 0a 02 14 0c 5f 50 53 30 00 50 53 30 5f 0a  Oh...._PS0.PS0_.
  3370: 02 14 0c 5f 50 53 33 00 50 53 33 5f 0a 02 5b 82  ..._PS3.PS3_..[.
  3380: 4f 20 43 4f 4d 32 14 39 5f 48 49 44 00 5b 23 57  O COM2.9_HID.[#W
  3390: 36 32 37 88 13 43 46 47 5f 0a 03 a0 0f 90 49 52  627..CFG_.....IR
  33a0: 4d 44 0a 38 70 0c 41 d0 05 10 61 a1 08 70 0c 41  MD.8p.A...a..p.A
  33b0: d0 05 01 61 58 43 46 47 5b 27 57 36 32 37 a4 61  ...aXCFG['W627.a
  33c0: 08 5f 55 49 44 0a 02 14 10 5f 53 54 41 00 70 53  ._UID...._STA.pS
  33d0: 54 41 5f 0a 03 61 a4 61 08 5f 50 52 57 12 06 02  TA_..a.a._PRW...
  33e0: 0a 08 0a 05 14 0c 5f 44 49 53 00 44 49 53 5f 0a  ......_DIS.DIS_.
  33f0: 03 14 43 0a 5f 43 52 53 00 08 52 53 52 43 11 10  ..C._CRS..RSRC..
  3400: 0a 0d 47 01 00 00 00 00 08 08 22 00 00 79 00 8c  ..G......."..y..
  3410: 52 53 52 43 0a 02 49 4f 31 5f 8c 52 53 52 43 0a  RSRC..IO1_.RSRC.
  3420: 03 49 4f 32 5f 8c 52 53 52 43 0a 04 49 4f 33 5f  .IO2_.RSRC..IO3_
  3430: 8c 52 53 52 43 0a 05 49 4f 34 5f 8b 52 53 52 43  .RSRC..IO4_.RSRC
  3440: 0a 09 49 52 51 56 5b 23 57 36 32 37 88 13 43 46  ..IRQV[#W627..CF
  3450: 47 5f 0a 03 70 49 4f 42 4c 49 4f 31 5f 70 49 4f  G_..pIOBLIO1_pIO
  3460: 42 48 49 4f 32 5f 70 49 4f 42 4c 49 4f 33 5f 70  BHIO2_pIOBLIO3_p
  3470: 49 4f 42 48 49 4f 34 5f 70 0a 01 60 79 60 49 4e  IOBHIO4_p..`y`IN
  3480: 54 5f 49 52 51 56 58 43 46 47 5b 27 57 36 32 37  T_IRQVXCFG['W627
  3490: a4 52 53 52 43 08 5f 50 52 53 11 44 07 0a 70 30  .RSRC._PRS.D..p0
  34a0: 47 01 f8 03 f8 03 01 08 23 10 00 01 31 00 47 01  G.......#...1.G.
  34b0: f8 02 f8 02 01 08 23 08 00 01 30 47 01 e8 03 e8  ......#...0G....
  34c0: 03 01 08 23 10 00 01 30 47 01 e8 02 e8 02 01 08  ...#...0G.......
  34d0: 23 08 00 01 31 0a 47 01 f8 03 f8 03 01 08 23 08  #...1.G.......#.
  34e0: 00 01 31 0a 47 01 f8 02 f8 02 01 08 23 10 00 01  ..1.G.......#...
  34f0: 31 0a 47 01 e8 03 e8 03 01 08 23 08 00 01 31 0a  1.G.......#...1.
  3500: 47 01 e8 02 e8 02 01 08 23 10 00 01 38 79 00 14  G.......#...8y..
  3510: 45 06 5f 53 52 53 01 8c 68 0a 02 49 4f 31 5f 8c  E._SRS..h..IO1_.
  3520: 68 0a 03 49 4f 32 5f 8b 68 0a 09 49 52 51 56 5b  h..IO2_.h..IRQV[
  3530: 23 57 36 32 37 88 13 43 46 47 5f 0a 03 70 49 4f  #W627..CFG_..pIO
  3540: 31 5f 49 4f 42 4c 70 49 4f 32 5f 49 4f 42 48 82  1_IOBLpIO2_IOBH.
  3550: 49 52 51 56 60 74 60 0a 01 49 4e 54 5f 70 0a 01  IRQV`t`..INT_p..
  3560: 41 43 54 5f 58 43 46 47 5b 27 57 36 32 37 43 4b  ACT_XCFG['W627CK
  3570: 49 4f 68 0a 03 14 0c 5f 50 53 30 00 50 53 30 5f  IOh...._PS0.PS0_
  3580: 0a 03 14 0c 5f 50 53 33 00 50 53 33 5f 0a 03 5b  ...._PS3.PS3_..[
  3590: 82 45 22 46 44 43 5f 08 5f 48 49 44 0c 41 d0 07  .E"FDC_._HID.A..
  35a0: 00 08 5f 55 49 44 0a 01 14 10 5f 53 54 41 00 70  .._UID...._STA.p
  35b0: 53 54 41 5f 0a 00 61 a4 61 14 0c 5f 44 49 53 00  STA_..a.a.._DIS.
  35c0: 44 49 53 5f 0a 00 14 4b 11 5f 43 52 53 00 08 52  DIS_...K._CRS..R
  35d0: 53 52 43 11 1b 0a 18 47 01 00 00 00 00 01 06 47  SRC....G.......G
  35e0: 01 00 00 00 00 01 01 22 00 00 2a 00 00 79 00 5b  ......."..*..y.[
  35f0: 23 57 36 32 37 88 13 43 46 47 5f 0a 00 8c 52 53  #W627..CFG_...RS
  3600: 52 43 0a 02 49 4f 31 5f 8c 52 53 52 43 0a 03 49  RC..IO1_.RSRC..I
  3610: 4f 32 5f 8c 52 53 52 43 0a 04 49 4f 33 5f 8c 52  O2_.RSRC..IO3_.R
  3620: 53 52 43 0a 05 49 4f 34 5f 8c 52 53 52 43 0a 0a  SRC..IO4_.RSRC..
  3630: 49 4f 35 5f 8c 52 53 52 43 0a 0b 49 4f 36 5f 8c  IO5_.RSRC..IO6_.
  3640: 52 53 52 43 0a 0c 49 4f 37 5f 8c 52 53 52 43 0a  RSRC..IO7_.RSRC.
  3650: 0d 49 4f 38 5f 8b 52 53 52 43 0a 11 49 52 51 56  .IO8_.RSRC..IRQV
  3660: 8c 52 53 52 43 0a 14 44 4d 41 56 70 49 4f 42 4c  .RSRC..DMAVpIOBL
  3670: 49 4f 31 5f 70 49 4f 42 48 49 4f 32 5f 70 49 4f  IO1_pIOBHIO2_pIO
  3680: 42 4c 49 4f 33 5f 70 49 4f 42 48 49 4f 34 5f 72  BLIO3_pIOBHIO4_r
  3690: 49 4f 42 4c 0a 07 49 4f 35 5f 70 49 4f 42 48 49  IOBL..IO5_pIOBHI
  36a0: 4f 36 5f 72 49 4f 42 4c 0a 07 49 4f 37 5f 70 49  O6_rIOBL..IO7_pI
  36b0: 4f 42 48 49 4f 38 5f 70 0a 01 60 79 60 49 4e 54  OBHIO8_p..`y`INT
  36c0: 5f 49 52 51 56 70 0a 01 60 79 60 44 4d 41 53 44  _IRQVp..`y`DMASD
  36d0: 4d 41 56 58 43 46 47 5b 27 57 36 32 37 a4 52 53  MAVXCFG['W627.RS
  36e0: 52 43 08 5f 50 52 53 11 38 0a 35 31 00 47 01 f0  RC._PRS.8.51.G..
  36f0: 03 f0 03 01 06 47 01 f7 03 f7 03 01 01 23 40 00  .....G.......#@.
  3700: 01 2a 04 00 31 00 47 01 70 03 70 03 01 06 47 01  .*..1.G.p.p...G.
  3710: 77 03 77 03 01 01 23 40 00 01 2a 04 00 38 79 00  w.w...#@..*..8y.
  3720: 14 4b 07 5f 53 52 53 01 8c 68 0a 02 49 4f 31 5f  .K._SRS..h..IO1_
  3730: 8c 68 0a 03 49 4f 32 5f 8b 68 0a 11 49 52 51 56  .h..IO2_.h..IRQV
  3740: 8c 68 0a 14 44 4d 41 56 5b 23 57 36 32 37 88 13  .h..DMAV[#W627..
  3750: 43 46 47 5f 0a 00 70 49 4f 31 5f 49 4f 42 4c 70  CFG_..pIO1_IOBLp
  3760: 49 4f 32 5f 49 4f 42 48 82 49 52 51 56 60 74 60  IO2_IOBH.IRQV`t`
  3770: 0a 01 49 4e 54 5f 82 44 4d 41 56 60 74 60 0a 01  ..INT_.DMAV`t`..
  3780: 44 4d 41 53 70 0a 01 41 43 54 5f 58 43 46 47 5b  DMASp..ACT_XCFG[
  3790: 27 57 36 32 37 43 4b 49 4f 68 0a 00 14 0c 5f 50  'W627CKIOh...._P
  37a0: 53 30 00 50 53 30 5f 0a 00 14 0c 5f 50 53 33 00  S0.PS0_...._PS3.
  37b0: 50 53 33 5f 0a 00 5b 82 49 52 50 52 54 5f 14 39  PS3_..[.IRPRT_.9
  37c0: 5f 48 49 44 00 5b 23 57 36 32 37 88 13 43 46 47  _HID.[#W627..CFG
  37d0: 5f 0a 01 a0 0f 93 4d 4f 44 45 0a 02 70 0c 41 d0  _.....MODE..p.A.
  37e0: 04 01 61 a1 08 70 0c 41 d0 04 00 61 58 43 46 47  ..a..p.A...aXCFG
  37f0: 5b 27 57 36 32 37 a4 61 08 5f 55 49 44 0a 02 14  ['W627.a._UID...
  3800: 10 5f 53 54 41 00 70 53 54 41 5f 0a 01 61 a4 61  ._STA.pSTA_..a.a
  3810: 14 0c 5f 44 49 53 00 44 49 53 5f 0a 01 14 48 24  .._DIS.DIS_...H$
  3820: 5f 43 52 53 00 5b 23 57 36 32 37 88 13 43 46 47  _CRS.[#W627..CFG
  3830: 5f 0a 01 08 43 52 53 41 11 10 0a 0d 47 01 00 00  _...CRSA....G...
  3840: 00 00 01 08 22 00 00 79 00 8c 43 52 53 41 0a 02  ...."..y..CRSA..
  3850: 49 4f 41 31 8c 43 52 53 41 0a 03 49 4f 41 32 8c  IOA1.CRSA..IOA2.
  3860: 43 52 53 41 0a 04 49 4f 41 33 8c 43 52 53 41 0a  CRSA..IOA3.CRSA.
  3870: 05 49 4f 41 34 8c 43 52 53 41 0a 06 41 4c 41 31  .IOA4.CRSA..ALA1
  3880: 8c 43 52 53 41 0a 07 4c 4e 41 31 8b 43 52 53 41  .CRSA..LNA1.CRSA
  3890: 0a 09 49 52 51 41 08 43 52 53 42 11 1b 0a 18 47  ..IRQA.CRSB....G
  38a0: 01 00 00 00 00 01 08 47 01 00 00 00 00 01 08 22  .......G......."
  38b0: 00 00 2a 00 02 79 00 8c 43 52 53 42 0a 02 49 4f  ..*..y..CRSB..IO
  38c0: 42 31 8c 43 52 53 42 0a 03 49 4f 42 32 8c 43 52  B1.CRSB..IOB2.CR
  38d0: 53 42 0a 04 49 4f 42 33 8c 43 52 53 42 0a 05 49  SB..IOB3.CRSB..I
  38e0: 4f 42 34 8c 43 52 53 42 0a 06 41 4c 42 31 8c 43  OB4.CRSB..ALB1.C
  38f0: 52 53 42 0a 07 4c 4e 42 31 8c 43 52 53 42 0a 0a  RSB..LNB1.CRSB..
  3900: 49 4f 42 35 8c 43 52 53 42 0a 0b 49 4f 42 36 8c  IOB5.CRSB..IOB6.
  3910: 43 52 53 42 0a 0c 49 4f 42 37 8c 43 52 53 42 0a  CRSB..IOB7.CRSB.
  3920: 0d 49 4f 42 38 8c 43 52 53 42 0a 0e 41 4c 42 32  .IOB8.CRSB..ALB2
  3930: 8c 43 52 53 42 0a 0f 4c 4e 42 32 8b 43 52 53 42  .CRSB..LNB2.CRSB
  3940: 0a 11 49 52 51 42 8b 43 52 53 42 0a 14 44 4d 41  ..IRQB.CRSB..DMA
  3950: 56 a0 43 0f 41 43 54 5f a0 4b 09 93 4d 4f 44 45  V.C.ACT_.K..MODE
  3960: 0a 02 70 49 4f 42 4c 49 4f 42 31 70 49 4f 42 48  ..pIOBLIOB1pIOBH
  3970: 49 4f 42 32 70 49 4f 42 4c 49 4f 42 33 70 49 4f  IOB2pIOBLIOB3pIO
  3980: 42 48 49 4f 42 34 70 49 4f 42 4c 49 4f 42 35 72  BHIOB4pIOBLIOB5r
  3990: 49 4f 42 48 0a 04 49 4f 42 36 70 49 4f 42 4c 49  IOBH..IOB6pIOBLI
  39a0: 4f 42 37 72 49 4f 42 48 0a 04 49 4f 42 38 a0 24  OB7rIOBH..IOB8.$
  39b0: 93 49 4f 42 4c 0a bc 70 0a 01 41 4c 42 31 70 0a  .IOBL..p..ALB1p.
  39c0: 04 4c 4e 42 31 70 0a 01 41 4c 42 32 70 0a 04 4c  .LNB1p..ALB2p..L
  39d0: 4e 42 32 70 0a 01 60 79 60 49 4e 54 5f 49 52 51  NB2p..`y`INT_IRQ
  39e0: 42 70 0a 01 60 79 60 44 4d 41 53 44 4d 41 56 a4  Bp..`y`DMASDMAV.
  39f0: 43 52 53 42 a1 40 05 70 49 4f 42 4c 49 4f 41 31  CRSB.@.pIOBLIOA1
  3a00: 70 49 4f 42 48 49 4f 41 32 70 49 4f 42 4c 49 4f  pIOBHIOA2pIOBLIO
  3a10: 41 33 70 49 4f 42 48 49 4f 41 34 70 0a 01 60 79  A3pIOBHIOA4p..`y
  3a20: 60 49 4e 54 5f 49 52 51 41 a0 16 93 49 4f 42 4c  `INT_IRQA...IOBL
  3a30: 0a bc 70 0a 01 41 4c 41 31 70 0a 04 4c 4e 41 31  ..p..ALA1p..LNA1
  3a40: a4 43 52 53 41 a1 16 a0 0d 93 4d 4f 44 45 0a 02  .CRSA.....MODE..
  3a50: a4 43 52 53 42 a1 06 a4 43 52 53 41 58 43 46 47  .CRSB...CRSAXCFG
  3a60: 5b 27 57 36 32 37 08 50 52 53 41 11 45 05 0a 51  ['W627.PRSA.E..Q
  3a70: 30 47 01 78 03 78 03 01 08 23 80 00 01 30 47 01  0G.x.x...#...0G.
  3a80: 78 03 78 03 01 08 23 20 00 01 30 47 01 78 02 78  x.x...# ..0G.x.x
  3a90: 02 01 08 23 80 00 01 30 47 01 78 02 78 02 01 08  ...#...0G.x.x...
  3aa0: 23 20 00 01 30 47 01 bc 03 bc 03 01 04 23 80 00  # ..0G.......#..
  3ab0: 01 30 47 01 bc 03 bc 03 01 04 23 20 00 01 38 79  .0G.......# ..8y
  3ac0: 00 08 50 52 53 42 11 47 09 0a 93 30 47 01 78 03  ..PRSB.G...0G.x.
  3ad0: 78 03 01 08 47 01 78 07 78 07 01 08 23 80 00 01  x...G.x.x...#...
  3ae0: 2a 0b 02 30 47 01 78 03 78 03 01 08 47 01 78 07  *..0G.x.x...G.x.
  3af0: 78 07 01 08 23 20 00 01 2a 0b 02 30 47 01 78 02  x...# ..*..0G.x.
  3b00: 78 02 01 08 47 01 78 06 78 06 01 08 23 80 00 01  x...G.x.x...#...
  3b10: 2a 0b 02 30 47 01 78 02 78 02 01 08 47 01 78 06  *..0G.x.x...G.x.
  3b20: 78 06 01 08 23 20 00 01 2a 0b 02 30 47 01 bc 03  x...# ..*..0G...
  3b30: bc 03 01 04 47 01 bc 07 bc 07 01 04 23 80 00 01  ....G.......#...
  3b40: 2a 0b 02 30 47 01 bc 03 bc 03 01 04 47 01 bc 07  *..0G.......G...
  3b50: bc 07 01 04 23 20 00 01 2a 0b 02 38 79 00 14 37  ....# ..*..8y..7
  3b60: 5f 50 52 53 00 5b 23 57 36 32 37 88 13 43 46 47  _PRS.[#W627..CFG
  3b70: 5f 0a 01 a0 0e 93 4d 4f 44 45 0a 02 70 50 52 53  _.....MODE..pPRS
  3b80: 42 60 a1 07 70 50 52 53 41 60 58 43 46 47 5b 27  B`..pPRSA`XCFG['
  3b90: 57 36 32 37 a4 60 14 40 13 5f 53 52 53 01 5b 23  W627.`.@._SRS.[#
  3ba0: 57 36 32 37 88 13 43 46 47 5f 0a 01 a0 47 0a 93  W627..CFG_...G..
  3bb0: 4d 4f 44 45 0a 02 8c 68 0a 02 49 4f 42 31 8c 68  MODE...h..IOB1.h
  3bc0: 0a 03 49 4f 42 32 8c 68 0a 04 49 4f 42 33 8c 68  ..IOB2.h..IOB3.h
  3bd0: 0a 05 49 4f 42 34 8c 68 0a 06 41 4c 42 31 8c 68  ..IOB4.h..ALB1.h
  3be0: 0a 07 4c 4e 42 31 8c 68 0a 0a 49 4f 42 35 8c 68  ..LNB1.h..IOB5.h
  3bf0: 0a 0b 49 4f 42 36 8c 68 0a 0c 49 4f 42 37 8c 68  ..IOB6.h..IOB7.h
  3c00: 0a 0d 49 4f 42 38 8c 68 0a 0e 41 4c 42 32 8c 68  ..IOB8.h..ALB2.h
  3c10: 0a 0f 4c 4e 42 32 8b 68 0a 11 49 52 51 42 8b 68  ..LNB2.h..IRQB.h
  3c20: 0a 14 44 4d 41 56 70 49 4f 42 31 49 4f 42 4c 70  ..DMAVpIOB1IOBLp
  3c30: 49 4f 42 32 49 4f 42 48 81 49 52 51 42 60 74 60  IOB2IOBH.IRQB`t`
  3c40: 0a 01 49 4e 54 5f 81 44 4d 41 56 60 74 60 0a 01  ..INT_.DMAV`t`..
  3c50: 44 4d 41 53 a1 4a 05 8c 68 0a 02 49 4f 41 31 8c  DMAS.J..h..IOA1.
  3c60: 68 0a 03 49 4f 41 32 8c 68 0a 04 49 4f 41 33 8c  h..IOA2.h..IOA3.
  3c70: 68 0a 05 49 4f 41 34 8c 68 0a 06 41 4c 41 31 8c  h..IOA4.h..ALA1.
  3c80: 68 0a 07 4c 4e 41 31 8b 68 0a 09 49 52 51 41 70  h..LNA1.h..IRQAp
  3c90: 49 4f 41 31 49 4f 42 4c 70 49 4f 41 32 49 4f 42  IOA1IOBLpIOA2IOB
  3ca0: 48 81 49 52 51 41 60 74 60 0a 01 49 4e 54 5f 70  H.IRQA`t`..INT_p
  3cb0: 0a 01 41 43 54 5f 58 43 46 47 5b 27 57 36 32 37  ..ACT_XCFG['W627
  3cc0: 43 4b 49 4f 68 0a 01 14 0c 5f 50 53 30 00 50 53  CKIOh...._PS0.PS
  3cd0: 30 5f 0a 01 14 0c 5f 50 53 33 00 50 53 33 5f 0a  0_...._PS3.PS3_.
  3ce0: 01 14 4f 06 45 4e 57 4b 00 5b 23 57 36 32 37 88  ..O.ENWK.[#W627.
  3cf0: 13 43 46 47 5f 0a 0a 70 0a 01 41 43 54 5f 70 0a  .CFG_..p..ACT_p.
  3d00: f3 49 4e 44 58 70 0a 3f 44 41 54 41 70 0a f6 49  .INDXp.?DATAp..I
  3d10: 4e 44 58 70 44 41 54 41 60 a0 0f 93 7b 60 0a 10  NDXpDATA`...{`..
  3d20: 00 00 70 0a ad 50 53 32 43 70 0a f9 49 4e 44 58  ..p..PS2Cp..INDX
  3d30: 70 0a 05 44 41 54 41 58 43 46 47 5b 27 57 36 32  p..DATAXCFG['W62
  3d40: 37 a0 0f 93 7b 60 0a 20 00 00 70 0a a7 50 53 32  7...{`. ..p..PS2
  3d50: 43 14 33 44 53 57 4b 00 5b 23 57 36 32 37 88 13  C.3DSWK.[#W627..
  3d60: 43 46 47 5f 0a 0a 70 0a 00 41 43 54 5f 70 0a f9  CFG_..p..ACT_p..
  3d70: 49 4e 44 58 70 0a 00 44 41 54 41 58 43 46 47 5b  INDXp..DATAXCFG[
  3d80: 27 57 36 32 37 14 24 43 4c 45 44 01 5b 23 57 36  'W627.$CLED.[#W6
  3d90: 32 37 88 13 43 46 47 5f 0a 09 70 68 53 4c 45 44  27..CFG_..phSLED
  3da0: 58 43 46 47 5b 27 57 36 32 37 08 4e 41 54 41 12  XCFG['W627.NATA.
  3db0: 07 01 0c 01 00 1f 00 5b 82 4e 87 49 44 45 43 08  .......[.N.IDEC.
  3dc0: 5f 41 44 52 0c 01 00 1f 00 5b 80 49 44 45 43 02  _ADR.....[.IDEC.
  3dd0: 0a 40 0a 18 5b 81 4f 05 49 44 45 43 03 50 52 49  .@..[.O.IDEC.PRI
  3de0: 54 10 53 45 43 54 10 50 53 49 54 04 53 53 49 54  T.SECT.PSIT.SSIT
  3df0: 04 00 18 53 44 4d 41 04 00 0c 53 44 54 30 02 00  ...SDMA...SDT0..
  3e00: 02 53 44 54 31 02 00 02 53 44 54 32 02 00 02 53  .SDT1...SDT2...S
  3e10: 44 54 33 02 00 42 04 49 43 52 30 04 49 43 52 31  DT3..B.ICR0.ICR1
  3e20: 04 49 43 52 32 04 49 43 52 33 04 49 43 52 34 04  .ICR2.ICR3.ICR4.
  3e30: 49 43 52 35 04 14 47 04 47 45 54 50 01 a3 a0 0f  ICR5..G.GETP....
  3e40: 93 7b 68 0a 09 00 0a 00 a4 0c ff ff ff ff a0 0d  .{h.............
  3e50: 93 7b 68 0a 09 00 0a 08 a4 0b 84 03 7a 7b 68 0b  .{h.........z{h.
  3e60: 00 03 00 0a 08 60 7a 7b 68 0b 00 30 00 0a 0c 61  .....`z{h..0...a
  3e70: a4 77 0a 1e 74 0a 09 72 60 61 00 00 00 14 2d 47  .w..t..r`a....-G
  3e80: 45 54 44 04 a3 a0 1f 68 a0 05 69 a4 0a 14 a0 0c  ETD....h..i.....
  3e90: 6a a4 77 74 0a 04 6b 00 0a 0f 00 a4 77 74 0a 04  j.wt..k.....wt..
  3ea0: 6b 00 0a 1e 00 a4 0c ff ff ff ff 14 20 47 45 54  k........... GET
  3eb0: 54 01 a3 a4 77 0a 1e 74 0a 09 72 7b 7a 68 0a 02  T...w..t..r{zh..
  3ec0: 00 0a 03 00 7b 68 0a 03 00 00 00 00 14 47 06 47  ....{h.......G.G
  3ed0: 45 54 46 03 a3 08 54 4d 50 46 0a 00 a0 0d 68 7d  ETF...TMPF....h}
  3ee0: 54 4d 50 46 0a 01 54 4d 50 46 a0 11 7b 6a 0a 02  TMPF..TMPF..{j..
  3ef0: 00 7d 54 4d 50 46 0a 02 54 4d 50 46 a0 0d 69 7d  .}TMPF..TMPF..i}
  3f00: 54 4d 50 46 0a 04 54 4d 50 46 a0 11 7b 6a 0a 20  TMPF..TMPF..{j.
  3f10: 00 7d 54 4d 50 46 0a 08 54 4d 50 46 a0 12 7b 6a  .}TMPF..TMPF..{j
  3f20: 0b 00 40 00 7d 54 4d 50 46 0a 10 54 4d 50 46 a4  ..@.}TMPF..TMPF.
  3f30: 54 4d 50 46 14 41 04 53 45 54 50 03 a3 a0 09 92  TMPF.A.SETP.....
  3f40: 95 68 0a f0 a4 0a 08 a1 2e a0 28 7b 69 0a 02 00  .h........({i...
  3f50: a0 10 90 92 94 68 0a 78 7b 6a 0a 02 00 a4 0b 01  .....h.x{j......
  3f60: 23 a0 10 90 92 94 68 0a b4 7b 6a 0a 01 00 a4 0b  #.....h..{j.....
  3f70: 01 21 a4 0b 01 10 14 3c 53 45 54 44 01 a3 a0 09  .!.....<SETD....
  3f80: 92 94 68 0a 14 a4 0a 01 a0 09 92 94 68 0a 1e a4  ..h.........h...
  3f90: 0a 02 a0 09 92 94 68 0a 2d a4 0a 01 a0 09 92 94  ......h.-.......
  3fa0: 68 0a 3c a4 0a 02 a0 09 92 94 68 0a 5a a4 0a 01  h.<.......h.Z...
  3fb0: a4 0a 00 14 31 53 45 54 54 03 a3 a0 26 7b 69 0a  ....1SETT...&{i.
  3fc0: 02 00 a0 0f 90 92 94 68 0a 78 7b 6a 0a 02 00 a4  .......h.x{j....
  3fd0: 0a 0b a0 0f 90 92 94 68 0a b4 7b 6a 0a 01 00 a4  .......h..{j....
  3fe0: 0a 09 a4 0a 04 5b 82 40 65 50 52 49 44 08 5f 41  .....[.@ePRID._A
  3ff0: 44 52 0a 00 14 4a 13 5f 47 54 4d 00 a3 08 50 42  DR...J._GTM...PB
  4000: 55 46 11 17 0a 14 00 00 00 00 00 00 00 00 00 00  UF..............
  4010: 00 00 00 00 00 00 00 00 00 00 8a 50 42 55 46 0a  ...........PBUF.
  4020: 00 50 49 4f 30 8a 50 42 55 46 0a 04 44 4d 41 30  .PIO0.PBUF..DMA0
  4030: 8a 50 42 55 46 0a 08 50 49 4f 31 8a 50 42 55 46  .PBUF..PIO1.PBUF
  4040: 0a 0c 44 4d 41 31 8a 50 42 55 46 0a 10 46 4c 41  ..DMA1.PBUF..FLA
  4050: 47 70 47 45 54 50 50 52 49 54 50 49 4f 30 70 47  GpGETPPRITPIO0pG
  4060: 45 54 44 7b 53 44 4d 41 0a 01 00 7b 49 43 52 33  ETD{SDMA...{ICR3
  4070: 0a 01 00 7b 49 43 52 30 0a 01 00 53 44 54 30 44  ...{ICR0...SDT0D
  4080: 4d 41 30 a0 14 93 44 4d 41 30 0c ff ff ff ff 70  MA0...DMA0.....p
  4090: 50 49 4f 30 44 4d 41 30 a0 2e 7b 50 52 49 54 0b  PIO0DMA0..{PRIT.
  40a0: 00 40 00 a0 14 93 7b 50 52 49 54 0a 90 00 0a 80  .@....{PRIT.....
  40b0: 70 0b 84 03 50 49 4f 31 a1 0e 70 47 45 54 54 50  p...PIO1..pGETTP
  40c0: 53 49 54 50 49 4f 31 a1 0b 70 0c ff ff ff ff 50  SITPIO1..p.....P
  40d0: 49 4f 31 70 47 45 54 44 7b 53 44 4d 41 0a 02 00  IO1pGETD{SDMA...
  40e0: 7b 49 43 52 33 0a 02 00 7b 49 43 52 30 0a 02 00  {ICR3...{ICR0...
  40f0: 53 44 54 31 44 4d 41 31 a0 14 93 44 4d 41 31 0c  SDT1DMA1...DMA1.
  4100: ff ff ff ff 70 50 49 4f 31 44 4d 41 31 70 47 45  ....pPIO1DMA1pGE
  4110: 54 46 7b 53 44 4d 41 0a 01 00 7b 53 44 4d 41 0a  TF{SDMA...{SDMA.
  4120: 02 00 50 52 49 54 46 4c 41 47 a4 50 42 55 46 14  ..PRITFLAG.PBUF.
  4130: 40 2f 5f 53 54 4d 03 a3 8a 68 0a 00 50 49 4f 30  @/_STM...h..PIO0
  4140: 8a 68 0a 04 44 4d 41 30 8a 68 0a 08 50 49 4f 31  .h..DMA0.h..PIO1
  4150: 8a 68 0a 0c 44 4d 41 31 8a 68 0a 10 46 4c 41 47  .h..DMA1.h..FLAG
  4160: 70 0a 04 49 43 52 32 a0 4e 13 93 87 69 0b 00 02  p..ICR2.N...i...
  4170: 7b 50 52 49 54 0b f0 4c 50 52 49 54 7b 53 44 4d  {PRIT..LPRIT{SDM
  4180: 41 0a 0e 53 44 4d 41 70 0a 00 53 44 54 30 7b 49  A..SDMAp..SDT0{I
  4190: 43 52 30 0a 0e 49 43 52 30 7b 49 43 52 31 0a 0e  CR0..ICR0{ICR1..
  41a0: 49 43 52 31 7b 49 43 52 33 0a 0e 49 43 52 33 7b  ICR1{ICR3..ICR3{
  41b0: 49 43 52 35 0a 0e 49 43 52 35 8b 69 0a 62 57 34  ICR5..ICR5.i.bW4
  41c0: 39 30 8b 69 0a 6a 57 35 33 30 8b 69 0a 7e 57 36  90.i.jW530.i.~W6
  41d0: 33 30 8b 69 0a 80 57 36 34 30 8b 69 0a b0 57 38  30.i..W640.i..W8
  41e0: 38 30 7d 50 52 49 54 0b 04 80 50 52 49 54 a0 1e  80}PRIT...PRIT..
  41f0: 90 7b 46 4c 41 47 0a 02 00 7b 57 34 39 30 0b 00  .{FLAG...{W490..
  4200: 08 00 7d 50 52 49 54 0a 02 50 52 49 54 7d 50 52  ..}PRIT..PRIT}PR
  4210: 49 54 53 45 54 50 50 49 4f 30 57 35 33 30 57 36  ITSETPPIO0W530W6
  4220: 34 30 50 52 49 54 a0 4f 07 7b 46 4c 41 47 0a 01  40PRIT.O.{FLAG..
  4230: 00 7d 53 44 4d 41 0a 01 53 44 4d 41 70 53 45 54  .}SDMA..SDMApSET
  4240: 44 44 4d 41 30 53 44 54 30 a0 1f 7b 57 38 38 30  DDMA0SDT0..{W880
  4250: 0a 20 00 7d 49 43 52 31 0a 01 49 43 52 31 7d 49  . .}ICR1..ICR1}I
  4260: 43 52 35 0a 01 49 43 52 35 a0 14 7b 57 38 38 30  CR5..ICR5..{W880
  4270: 0a 10 00 7d 49 43 52 31 0a 01 49 43 52 31 a0 13  ...}ICR1..ICR1..
  4280: 95 44 4d 41 30 0a 1e 7d 49 43 52 33 0a 01 49 43  .DMA0..}ICR3..IC
  4290: 52 33 a0 13 95 44 4d 41 30 0a 3c 7d 49 43 52 30  R3...DMA0.<}ICR0
  42a0: 0a 01 49 43 52 30 a0 49 17 93 87 6a 0b 00 02 7b  ..ICR0.I...j...{
  42b0: 50 52 49 54 0b 0f 3f 50 52 49 54 70 0a 00 50 53  PRIT..?PRITp..PS
  42c0: 49 54 7b 53 44 4d 41 0a 0d 53 44 4d 41 70 0a 00  IT{SDMA..SDMAp..
  42d0: 53 44 54 31 7b 49 43 52 30 0a 0d 49 43 52 30 7b  SDT1{ICR0..ICR0{
  42e0: 49 43 52 31 0a 0d 49 43 52 31 7b 49 43 52 33 0a  ICR1..ICR1{ICR3.
  42f0: 0d 49 43 52 33 7b 49 43 52 35 0a 0d 49 43 52 35  .ICR3{ICR5..ICR5
  4300: 8b 6a 0a 62 57 34 39 31 8b 6a 0a 6a 57 35 33 31  .j.bW491.j.jW531
  4310: 8b 6a 0a 7e 57 36 33 31 8b 6a 0a 80 57 36 34 31  .j.~W631.j..W641
  4320: 8b 6a 0a b0 57 38 38 31 7d 50 52 49 54 0b 40 80  .j..W881}PRIT.@.
  4330: 50 52 49 54 a0 1e 90 7b 46 4c 41 47 0a 08 00 7b  PRIT...{FLAG...{
  4340: 57 34 39 31 0b 00 08 00 7d 50 52 49 54 0a 20 50  W491....}PRIT. P
  4350: 52 49 54 a0 4c 04 7b 46 4c 41 47 0a 10 00 7d 50  RIT.L.{FLAG...}P
  4360: 52 49 54 0b 00 40 50 52 49 54 a0 13 94 50 49 4f  RIT..@PRIT...PIO
  4370: 31 0a f0 7d 50 52 49 54 0a 80 50 52 49 54 a1 21  1..}PRIT..PRIT.!
  4380: 7d 50 52 49 54 0a 10 50 52 49 54 70 53 45 54 54  }PRIT..PRITpSETT
  4390: 50 49 4f 31 57 35 33 31 57 36 34 31 50 53 49 54  PIO1W531W641PSIT
  43a0: a0 4f 07 7b 46 4c 41 47 0a 04 00 7d 53 44 4d 41  .O.{FLAG...}SDMA
  43b0: 0a 02 53 44 4d 41 70 53 45 54 44 44 4d 41 31 53  ..SDMApSETDDMA1S
  43c0: 44 54 31 a0 1f 7b 57 38 38 31 0a 20 00 7d 49 43  DT1..{W881. .}IC
  43d0: 52 31 0a 02 49 43 52 31 7d 49 43 52 35 0a 02 49  R1..ICR1}ICR5..I
  43e0: 43 52 35 a0 14 7b 57 38 38 31 0a 10 00 7d 49 43  CR5..{W881...}IC
  43f0: 52 31 0a 02 49 43 52 31 a0 13 95 44 4d 41 30 0a  R1..ICR1...DMA0.
  4400: 1e 7d 49 43 52 33 0a 02 49 43 52 33 a0 13 95 44  .}ICR3..ICR3...D
  4410: 4d 41 30 0a 3c 7d 49 43 52 30 0a 02 49 43 52 30  MA0.<}ICR0..ICR0
  4420: 14 07 5f 50 53 30 00 a3 14 07 5f 50 53 33 00 a3  .._PS0...._PS3..
  4430: 5b 82 44 10 50 5f 44 30 08 5f 41 44 52 0a 00 14  [.D.P_D0._ADR...
  4440: 46 0f 5f 47 54 46 00 a3 08 50 49 42 30 11 11 0a  F._GTF...PIB0...
  4450: 0e 03 00 00 00 00 a0 ef 03 00 00 00 00 a0 ef 8c  ................
  4460: 50 49 42 30 0a 01 50 4d 44 30 8c 50 49 42 30 0a  PIB0..PMD0.PIB0.
  4470: 08 44 4d 44 30 a0 40 06 7b 50 52 49 54 0a 02 00  .DMD0.@.{PRIT...
  4480: a0 13 93 7b 50 52 49 54 0a 09 00 0a 08 70 0a 08  ...{PRIT.....p..
  4490: 50 4d 44 30 a1 41 04 70 0a 0a 50 4d 44 30 7a 7b  PMD0.A.p..PMD0z{
  44a0: 50 52 49 54 0b 00 03 00 0a 08 60 7a 7b 50 52 49  PRIT......`z{PRI
  44b0: 54 0b 00 30 00 0a 0c 61 72 60 61 62 a0 0c 93 0a  T..0...ar`ab....
  44c0: 03 62 70 0a 0b 50 4d 44 30 a0 0c 93 0a 05 62 70  .bp..PMD0.....bp
  44d0: 0a 0c 50 4d 44 30 a1 08 70 0a 01 50 4d 44 30 a0  ..PMD0..p..PMD0.
  44e0: 3c 7b 53 44 4d 41 0a 01 00 70 7d 53 44 54 30 0a  <{SDMA...p}SDT0.
  44f0: 40 00 44 4d 44 30 a0 14 7b 49 43 52 30 0a 01 00  @.DMD0..{ICR0...
  4500: 72 44 4d 44 30 0a 02 44 4d 44 30 a0 10 7b 49 43  rDMD0..DMD0..{IC
  4510: 52 33 0a 01 00 70 0a 45 44 4d 44 30 a1 14 7d 74  R3...p.EDMD0..}t
  4520: 7b 50 4d 44 30 0a 07 00 0a 02 00 0a 20 44 4d 44  {PMD0....... DMD
  4530: 30 a4 50 49 42 30 5b 82 4f 0f 50 5f 44 31 08 5f  0.PIB0[.O.P_D1._
  4540: 41 44 52 0a 01 14 41 0f 5f 47 54 46 00 a3 08 50  ADR...A._GTF...P
  4550: 49 42 31 11 11 0a 0e 03 00 00 00 00 b0 ef 03 00  IB1.............
  4560: 00 00 00 b0 ef 8c 50 49 42 31 0a 01 50 4d 44 31  ......PIB1..PMD1
  4570: 8c 50 49 42 31 0a 08 44 4d 44 31 a0 4b 05 7b 50  .PIB1..DMD1.K.{P
  4580: 52 49 54 0a 20 00 a0 13 93 7b 50 52 49 54 0a 90  RIT. ....{PRIT..
  4590: 00 0a 80 70 0a 08 50 4d 44 31 a1 3c 72 7b 50 53  ...p..PMD1.<r{PS
  45a0: 49 54 0a 03 00 7a 7b 50 53 49 54 0a 0c 00 0a 02  IT...z{PSIT.....
  45b0: 00 60 a0 0c 93 0a 05 60 70 0a 0c 50 4d 44 31 a1  .`.....`p..PMD1.
  45c0: 17 a0 0c 93 0a 03 60 70 0a 0b 50 4d 44 31 a1 08  ......`p..PMD1..
  45d0: 70 0a 0a 50 4d 44 31 a1 08 70 0a 01 50 4d 44 31  p..PMD1..p..PMD1
  45e0: a0 3c 7b 53 44 4d 41 0a 02 00 70 7d 53 44 54 31  .<{SDMA...p}SDT1
  45f0: 0a 40 00 44 4d 44 31 a0 14 7b 49 43 52 30 0a 02  .@.DMD1..{ICR0..
  4600: 00 72 44 4d 44 31 0a 02 44 4d 44 31 a0 10 7b 49  .rDMD1..DMD1..{I
  4610: 43 52 33 0a 02 00 70 0a 45 44 4d 44 31 a1 14 7d  CR3...p.EDMD1..}
  4620: 74 7b 50 4d 44 31 0a 07 00 0a 02 00 0a 20 44 4d  t{PMD1....... DM
  4630: 44 31 a4 50 49 42 31 5b 82 0f 53 4d 42 53 08 5f  D1.PIB1[..SMBS._
  4640: 41 44 52 0c 03 00 1f 00 5b 82 19 50 57 52 42 08  ADR.....[..PWRB.
  4650: 5f 48 49 44 0c 41 d0 0c 0c 14 09 5f 53 54 41 00  _HID.A....._STA.
  4660: a4 0a 0b 10 0c 5f 53 49 5f 14 06 5f 53 53 54 01  ....._SI_.._SST.
  4670: 10 05 5f 54 5a 5f 08 5f 53 30 5f 12 06 02 0a 00  .._TZ_._S0_.....
  4680: 0a 00 08 5f 53 31 5f 12 06 02 0a 01 0a 01 08 5f  ..._S1_........_
  4690: 53 33 5f 12 06 02 0a 05 0a 05 08 5f 53 34 5f 12  S3_........_S4_.
  46a0: 06 02 0a 06 0a 06 08 5f 53 35 5f 12 06 02 0a 07  ......._S5_.....
  46b0: 0a 07 08 50 49 43 46 0a 00 14 0d 5f 50 49 43 01  ...PICF...._PIC.
  46c0: 70 68 5c 50 49 43 46 14 40 21 5f 50 54 53 01 70  ph\PICF.@!_PTS.p
  46d0: 68 5c 2f 03 5f 53 42 5f 50 43 49 30 50 54 38 30  h\/._SB_PCI0PT80
  46e0: 70 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30 50 30  p..\/._SB_PCI0P0
  46f0: 50 31 50 4d 45 53 70 0a 01 5c 2f 04 5f 53 42 5f  P1PMESp..\/._SB_
  4700: 50 43 49 30 50 30 50 31 50 4d 45 53 70 0a 01 5c  PCI0P0P1PMESp..\
  4710: 2f 04 5f 53 42 5f 50 43 49 30 50 30 50 35 50 4d  /._SB_PCI0P0P5PM
  4720: 45 53 70 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30  ESp..\/._SB_PCI0
  4730: 50 30 50 35 50 4d 45 53 70 0a 01 5c 2f 04 5f 53  P0P5PMESp..\/._S
  4740: 42 5f 50 43 49 30 50 30 50 39 50 4d 45 53 70 0a  B_PCI0P0P9PMESp.
  4750: 01 5c 2f 04 5f 53 42 5f 50 43 49 30 50 30 50 39  .\/._SB_PCI0P0P9
  4760: 50 4d 45 53 70 0a 01 5c 2f 04 5f 53 42 5f 50 43  PMESp..\/._SB_PC
  4770: 49 30 50 45 58 30 50 4d 45 53 70 0a 01 5c 2f 04  I0PEX0PMESp..\/.
  4780: 5f 53 42 5f 50 43 49 30 50 45 58 30 50 4d 45 53  _SB_PCI0PEX0PMES
  4790: 70 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30 50 45  p..\/._SB_PCI0PE
  47a0: 58 30 50 4d 53 53 a0 46 0e 93 68 0a 01 70 0a 01  X0PMSS.F..h..p..
  47b0: 5c 2f 04 5f 53 42 5f 50 43 49 30 50 30 50 31 50  \/._SB_PCI0P0P1P
  47c0: 4d 45 49 70 0a 01 5c 2f 04 5f 53 42 5f 50 43 49  MEIp..\/._SB_PCI
  47d0: 30 50 30 50 31 50 47 50 45 70 0a 01 5c 2f 04 5f  0P0P1PGPEp..\/._
  47e0: 53 42 5f 50 43 49 30 50 30 50 35 50 4d 45 49 70  SB_PCI0P0P5PMEIp
  47f0: 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30 50 30 50  ..\/._SB_PCI0P0P
  4800: 35 50 47 50 45 70 0a 01 5c 2f 04 5f 53 42 5f 50  5PGPEp..\/._SB_P
  4810: 43 49 30 50 30 50 39 50 4d 45 49 70 0a 01 5c 2f  CI0P0P9PMEIp..\/
  4820: 04 5f 53 42 5f 50 43 49 30 50 30 50 39 50 47 50  ._SB_PCI0P0P9PGP
  4830: 45 70 0a 01 5c 2f 04 5f 53 42 5f 50 43 49 30 50  Ep..\/._SB_PCI0P
  4840: 45 58 30 50 53 43 49 70 0a 01 5c 2f 04 5f 53 42  EX0PSCIp..\/._SB
  4850: 5f 50 43 49 30 4c 50 43 30 42 50 45 45 5c 2f 05  _PCI0LPC0BPEE\/.
  4860: 5f 53 42 5f 50 43 49 30 4c 50 43 30 53 49 4f 5f  _SB_PCI0LPC0SIO_
  4870: 45 4e 57 4b 5c 2f 05 5f 53 42 5f 50 43 49 30 4c  ENWK\/._SB_PCI0L
  4880: 50 43 30 53 49 4f 5f 43 4c 45 44 0a 02 a0 1e 93  PC0SIO_CLED.....
  4890: 68 0a 03 5c 2f 05 5f 53 42 5f 50 43 49 30 4c 50  h..\/._SB_PCI0LP
  48a0: 43 30 53 49 4f 5f 43 4c 45 44 0a 03 a0 2b 92 95  C0SIO_CLED...+..
  48b0: 68 0a 04 5c 2f 05 5f 53 42 5f 50 43 49 30 4c 50  h..\/._SB_PCI0LP
  48c0: 43 30 53 49 4f 5f 43 4c 45 44 0a 00 5c 2e 5f 53  C0SIO_CLED..\._S
  48d0: 42 5f 50 48 53 52 0a 4b 14 47 13 5f 57 41 4b 01  B_PHSR.K.G._WAK.
  48e0: 79 68 0a 04 5c 2f 03 5f 53 42 5f 50 43 49 30 50  yh..\/._SB_PCI0P
  48f0: 54 38 30 5c 2f 05 5f 53 42 5f 50 43 49 30 4c 50  T80\/._SB_PCI0LP
  4900: 43 30 53 49 4f 5f 43 4c 45 44 0a 01 86 5c 2f 03  C0SIO_CLED...\/.
  4910: 5f 53 42 5f 50 43 49 30 50 57 52 42 0a 02 a0 46  _SB_PCI0PWRB...F
  4920: 0b 93 68 0a 01 70 0a 00 5c 2f 04 5f 53 42 5f 50  ..h..p..\/._SB_P
  4930: 43 49 30 50 30 50 31 50 4d 45 49 70 0a 00 5c 2f  CI0P0P1PMEIp..\/
  4940: 04 5f 53 42 5f 50 43 49 30 50 30 50 31 50 47 50  ._SB_PCI0P0P1PGP
  4950: 45 70 0a 00 5c 2f 04 5f 53 42 5f 50 43 49 30 50  Ep..\/._SB_PCI0P
  4960: 30 50 35 50 4d 45 49 70 0a 00 5c 2f 04 5f 53 42  0P5PMEIp..\/._SB
  4970: 5f 50 43 49 30 50 30 50 35 50 47 50 45 70 0a 00  _PCI0P0P5PGPEp..
  4980: 5c 2f 04 5f 53 42 5f 50 43 49 30 50 30 50 39 50  \/._SB_PCI0P0P9P
  4990: 4d 45 49 70 0a 00 5c 2f 04 5f 53 42 5f 50 43 49  MEIp..\/._SB_PCI
  49a0: 30 50 30 50 39 50 47 50 45 70 0a 00 5c 2f 04 5f  0P0P9PGPEp..\/._
  49b0: 53 42 5f 50 43 49 30 50 45 58 30 50 53 43 49 70  SB_PCI0PEX0PSCIp
  49c0: 0a 00 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50 43  ..\/._SB_PCI0LPC
  49d0: 30 42 50 45 45 a0 1b 93 68 0a 03 86 5c 2f 04 5f  0BPEE...h...\/._
  49e0: 53 42 5f 50 43 49 30 50 30 50 39 42 4d 46 33 0a  SB_PCI0P0P9BMF3.
  49f0: 00 5c 2f 05 5f 53 42 5f 50 43 49 30 4c 50 43 30  .\/._SB_PCI0LPC0
  4a00: 53 49 4f 5f 44 53 57 4b a4 12 06 02 0a 00 0a 00  SIO_DSWK........

FACS @ 0xbff61fc0
  0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00  FACS@...........
  0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0020: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

FACP @ 0xbff602ec
  0000: 46 41 43 50 f4 00 00 00 03 27 49 4e 54 45 4c 20  FACP.....'INTEL
  0010: 53 54 4f 41 4b 4c 45 59 00 00 04 06 50 54 4c 20  STOAKLEY....PTL
  0020: 03 00 00 00 c0 1f f6 bf 68 b8 f5 bf 01 00 09 00  ........h.......
  0030: b2 00 00 00 f0 f1 00 80 00 10 00 00 00 00 00 00  ................
  0040: 04 10 00 00 00 00 00 00 20 10 00 00 08 10 00 00  ........ .......
  0050: 28 10 00 00 00 00 00 00 04 02 01 04 08 00 00 85  (...............
  0060: 65 00 e9 03 00 00 00 00 01 03 0d 00 32 00 00 00  e...........2...
  0070: a5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0080: 00 00 00 00 c0 1f f6 bf 00 00 00 00 68 b8 f5 bf  ............h...
  0090: 00 00 00 00 01 20 00 00 00 10 00 00 00 00 00 00  ..... ..........
  00a0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 00  ................
  00b0: 04 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00c0: 00 00 00 00 01 08 00 00 20 10 00 00 00 00 00 00  ........ .......
  00d0: 01 20 00 00 08 10 00 00 00 00 00 00 01 40 00 00  . ...........@..
  00e0: 28 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (...............
  00f0: 00 00 00 00                                      ....

Wrong checksum for
 @ 0xbff603e0
  0000: 00 4d 41 52 e0 00 00 00 01 2f 49 6e 74 65 6c 20  .MAR...../Intel
  0010: 4f 45 4d 44 4d 41 52 20 00 00 04 06 4c 4f 48 52  OEMDMAR ....LOHR
  0020: 01 00 00 00 25 00 00 00 00 00 00 00 00 00 00 00  ....%...........
  0030: 00 00 18 00 00 00 00 00 00 00 71 fe 00 00 00 00  ..........q.....
  0040: 02 08 00 00 00 00 01 00 00 00 18 00 00 00 00 00  ................
  0050: 00 40 71 fe 00 00 00 00 02 08 00 00 00 00 05 00  .@q.............
  0060: 00 00 18 00 00 00 00 00 00 90 71 fe 00 00 00 00  ..........q.....
  0070: 02 08 00 00 00 00 09 00 00 00 18 00 00 00 00 00  ................
  0080: 00 a0 71 fe 00 00 00 00 01 08 00 00 00 00 0f 00  ..q.............
  0090: 00 00 10 00 01 00 00 00 00 80 71 fe 00 00 00 00  ..........q.....
  00a0: 01 00 40 00 00 00 00 00 00 b0 f6 bf 00 00 00 00  ..@.............
  00b0: ff 2f f7 bf 00 00 00 00 01 08 00 00 00 00 1d 00  ./..............
  00c0: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02  ................
  00d0: 01 08 00 00 00 00 1d 03 01 08 00 00 00 00 1d 07  ................

TCPA @ 0xbff604c0
  0000: 54 43 50 41 32 00 00 00 01 83 49 6e 74 65 6c 20  TCPA2.....Intel
  0010: 53 54 4f 41 4b 4c 45 59 00 00 04 06 4c 4f 48 52  STOAKLEY....LOHR
  0020: 5a 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  Z...............
  0030: 00 00                                            ..

APIC @ 0xbff604f2
  0000: 41 50 49 43 d4 00 00 00 01 a9 50 54 4c 54 44 20  APIC......PTLTD
  0010: 09 20 41 50 49 43 20 20 00 00 04 06 20 4c 54 50  . APIC  .... LTP
  0020: 00 00 00 00 00 00 e0 fe 01 00 00 00 00 08 00 00  ................
  0030: 01 00 00 00 00 08 01 04 01 00 00 00 00 08 02 01  ................
  0040: 01 00 00 00 00 08 03 05 01 00 00 00 00 08 04 02  ................
  0050: 01 00 00 00 00 08 05 06 01 00 00 00 00 08 06 03  ................
  0060: 01 00 00 00 00 08 07 07 01 00 00 00 01 0c 08 00  ................
  0070: 00 00 c0 fe 00 00 00 00 01 0c 09 00 00 80 c8 fe  ................
  0080: 18 00 00 00 01 0c 0a 00 00 90 c8 fe 30 00 00 00  ............0...
  0090: 04 06 00 05 00 01 04 06 01 05 00 01 04 06 02 05  ................
  00a0: 00 01 04 06 03 05 00 01 04 06 04 05 00 01 04 06  ................
  00b0: 05 05 00 01 04 06 06 05 00 01 04 06 07 05 00 01  ................
  00c0: 02 0a 00 00 02 00 00 00 05 00 02 0a 00 09 09 00  ................
  00d0: 00 00 0d 00                                      ....

MCFG @ 0xbff605c6
  0000: 4d 43 46 47 3c 00 00 00 01 5e 50 54 4c 54 44 20  MCFG<....^PTLTD
  0010: 20 20 4d 43 46 47 20 20 00 00 04 06 20 4c 54 50    MCFG  .... LTP
  0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0  ................
  0030: 00 00 00 00 00 00 00 09 00 00 00 00              ............

HPET @ 0xbff60602
  0000: 48 50 45 54 38 00 00 00 01 29 50 54 4c 54 44 20  HPET8....)PTLTD
  0010: 48 50 45 54 54 42 4c 20 00 00 04 06 20 4c 54 50  HPETTBL .... LTP
  0020: 01 00 00 00 01 a2 86 80 00 00 00 00 00 00 d0 fe  ................
  0030: 00 00 00 00 00 00 00 00                          ........

BOOT @ 0xbff6063a
  0000: 42 4f 4f 54 28 00 00 00 01 9a 50 54 4c 54 44 20  BOOT(.....PTLTD
  0010: 24 53 42 46 54 42 4c 24 00 00 04 06 20 4c 54 50  $SBFTBL$.... LTP
  0020: 01 00 00 00 41 00 00 00                          ....A...

SPCR @ 0xbff60662
  0000: 53 50 43 52 50 00 00 00 01 93 50 54 4c 54 44 20  SPCRP.....PTLTD
  0010: 24 55 43 52 54 42 4c 24 00 00 04 06 50 54 4c 20  $UCRTBL$....PTL
  0020: 01 00 00 00 00 00 00 00 01 08 00 00 f8 03 00 00  ................
  0030: 00 00 00 00 01 04 00 00 00 00 05 00 01 02 03 00  ................
  0040: ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00  ................

ERST @ 0xbff606b2
  0000: 45 52 53 54 90 05 00 00 01 69 53 4d 43 49 20 20  ERST.....iSMCI
  0010: 45 52 53 54 54 42 4c 20 00 00 04 06 53 4d 43 49  ERSTTBL ....SMCI
  0020: 01 00 00 00 0c 00 00 00 00 00 00 00 2b 00 00 00  ............+...
  0030: 00 03 00 00 00 08 00 01 00 41 f6 bf 00 00 00 00  .........A......
  0040: 00 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0050: 00 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0060: 00 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0070: 00 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0080: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0090: 01 03 00 00 00 08 00 01 00 41 f6 bf 00 00 00 00  .........A......
  00a0: 01 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  00b0: 01 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  00c0: 01 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  00d0: 01 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  00e0: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  00f0: 02 03 00 00 00 08 00 01 00 41 f6 bf 00 00 00 00  .........A......
  0100: 02 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0110: 02 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0120: 02 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0130: 02 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0140: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0150: 03 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0160: 03 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0170: 03 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0180: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0190: 04 02 00 00 00 20 00 03 01 41 f6 bf 00 00 00 00  ..... ...A......
  01a0: 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  ................
  01b0: 04 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  01c0: 04 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  01d0: 04 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  01e0: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  01f0: 05 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0200: 05 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0210: 05 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0220: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0230: 06 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0240: 06 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0250: 06 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0260: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0270: 06 01 00 00 00 08 00 01 05 41 f6 bf 00 00 00 00  .........A......
  0280: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
  0290: 07 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  02a0: 07 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  02b0: 07 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  02c0: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  02d0: 07 00 00 00 00 08 00 01 06 41 f6 bf 00 00 00 00  .........A......
  02e0: 00 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  02f0: 08 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0300: 08 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0310: 08 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0320: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0330: 08 00 00 00 00 40 00 04 07 41 f6 bf 00 00 00 00  .....@...A......
  0340: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff  ................
  0350: 09 02 00 00 00 40 00 04 0f 41 f6 bf 00 00 00 00  .....@...A......
  0360: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff  ................
  0370: 09 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0380: 09 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0390: 09 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  03a0: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  03b0: 0a 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  03c0: 0a 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  03d0: 0a 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  03e0: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  03f0: 0a 00 00 00 00 08 00 01 17 41 f6 bf 00 00 00 00  .........A......
  0400: 00 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0410: 0b 03 00 00 00 08 00 01 00 41 f6 bf 00 00 00 00  .........A......
  0420: 0b 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0430: 0b 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0440: 0b 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0450: 0b 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0460: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0470: 0d 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0480: 0d 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0490: 0d 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  04a0: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  04b0: 0d 00 00 00 00 40 00 04 18 41 f6 bf 00 00 00 00  .....@...A......
  04c0: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff  ................
  04d0: 0e 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  04e0: 0e 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  04f0: 0e 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0500: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0510: 0e 00 00 00 00 20 00 03 20 41 f6 bf 00 00 00 00  ..... .. A......
  0520: 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  ................
  0530: 0f 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0540: 0f 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0550: 0f 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0560: d1 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0570: 0f 00 00 00 00 10 00 02 24 41 f6 bf 00 00 00 00  ........$A......
  0580: 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00  ................

HEST @ 0xbff60c42
  0000: 48 45 53 54 a8 00 00 00 01 c3 53 4d 43 49 20 20  HEST......SMCI
  0010: 48 45 53 54 54 42 4c 20 00 00 04 06 53 4d 43 49  HESTTBL ....SMCI
  0020: 01 00 00 00 02 00 00 00 09 00 09 00 ff ff 03 01  ................
  0030: 01 00 00 00 01 00 00 00 9d 00 00 00 00 40 00 04  .............@..
  0040: 00 48 f6 bf 00 00 00 00 00 1c 00 00 58 02 00 00  .H..........X...
  0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0060: 00 00 00 00 9d 00 00 00 09 00 0a 00 ff ff 03 01  ................
  0070: 01 00 00 00 01 00 00 00 9d 00 00 00 00 40 00 04  .............@..
  0080: 08 48 f6 bf 00 00 00 00 00 1c 00 00 c8 00 00 00  .H..............
  0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00a0: 00 00 00 00 9d 00 00 00                          ........

BERT @ 0xbff60cea
  0000: 42 45 52 54 30 00 00 00 01 d3 53 4d 43 49 20 20  BERT0.....SMCI
  0010: 42 45 52 54 54 42 4c 20 00 00 04 06 53 4d 43 49  BERTTBL ....SMCI
  0020: 01 00 00 00 00 04 00 00 00 44 f6 bf 00 00 00 00  .........D......

EINJ @ 0xbff60d1a
  0000: 45 49 4e 4a 70 01 00 00 01 23 53 4d 43 49 20 20  EINJp....#SMCI
  0010: 45 49 4e 4a 54 42 4c 20 00 00 04 06 53 4d 43 49  EINJTBL ....SMCI
  0020: 01 00 00 00 0c 00 00 00 00 00 00 00 0a 00 00 00  ................
  0030: 00 03 00 00 00 08 00 01 00 40 f6 bf 00 00 00 00  .........@......
  0040: 00 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0050: 01 00 00 00 00 40 00 04 01 40 f6 bf 00 00 00 00  .....@...@......
  0060: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff  ................
  0070: 02 02 00 00 00 20 00 03 09 40 f6 bf 00 00 00 00  ..... ...@......
  0080: 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  ................
  0090: 03 00 00 00 00 20 00 03 0d 40 f6 bf 00 00 00 00  ..... ...@......
  00a0: 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00  ................
  00b0: 04 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  00c0: 04 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  00d0: 04 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  00e0: d0 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  00f0: 05 03 00 00 01 08 00 01 b3 00 00 00 00 00 00 00  ................
  0100: 05 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0110: 05 03 00 00 01 08 00 01 b2 00 00 00 00 00 00 00  ................
  0120: d0 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00  ................
  0130: 06 01 00 00 00 08 00 01 11 40 f6 bf 00 00 00 00  .........@......
  0140: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
  0150: 07 00 00 00 00 10 00 02 12 40 f6 bf 00 00 00 00  .........@......
  0160: 00 00 00 00 00 00 00 00 fe 01 00 00 00 00 00 00  ................

SLIC @ 0xbff60e8a
  0000: 53 4c 49 43 76 01 00 00 01 b9 4f 45 4d 5f 49 44  SLICv.....OEM_ID
  0010: 4f 45 4d 54 41 42 4c 45 00 00 04 06 20 4c 54 50  OEMTABLE.... LTP
  0020: 00 00 00 00 00 00 00 00 9c 00 00 00 06 02 00 00  ................
  0030: 00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00  .$..RSA1........
  0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  00c0: 01 00 00 00 b6 00 00 00 00 00 02 00 ff ff ff ff  ................
  00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
  0170: ff ff ff ff ff ff                                ......

SSDT @ 0xbff5a16f
  0000: 53 53 44 54 5f 02 00 00 01 c8 50 6d 52 65 66 00  SSDT_.....PmRef.
  0010: 43 70 75 30 54 73 74 00 00 30 00 00 49 4e 54 4c  Cpu0Tst..0..INTL
  0020: 28 02 05 20 10 4a 23 5c 2e 5f 50 52 5f 43 50 55  (.. .J#\._PR_CPU
  0030: 30 08 5f 54 50 43 0a 00 14 4d 06 5f 50 54 43 00  0._TPC...M._PTC.
  0040: a0 37 7b 50 44 43 30 0a 04 00 a4 12 2c 02 11 14  .7{PDC0.....,...
  0050: 0a 11 82 0c 00 7f 00 00 00 00 00 00 00 00 00 00  ................
  0060: 00 79 00 11 14 0a 11 82 0c 00 7f 00 00 00 00 00  .y..............
  0070: 00 00 00 00 00 00 79 00 a4 12 2c 02 11 14 0a 11  ......y...,.....
  0080: 82 0c 00 01 04 01 00 10 10 00 00 00 00 00 00 79  ...............y
  0090: 00 11 14 0a 11 82 0c 00 01 04 01 00 10 10 00 00  ................
  00a0: 00 00 00 00 79 00 08 54 53 53 49 12 41 07 08 12  ....y..TSSI.A...
  00b0: 0d 05 0a 64 0b e8 03 0a 00 0a 00 0a 00 12 0d 05  ...d............
  00c0: 0a 58 0b 6b 03 0a 00 0a 0f 0a 00 12 0d 05 0a 4b  .X.k...........K
  00d0: 0b ee 02 0a 00 0a 0e 0a 00 12 0d 05 0a 3f 0b 71  .............?.q
  00e0: 02 0a 00 0a 0d 0a 00 12 0d 05 0a 32 0b f4 01 0a  ...........2....
  00f0: 00 0a 0c 0a 00 12 0d 05 0a 26 0b 77 01 0a 00 0a  .........&.w....
  0100: 0b 0a 00 12 0c 05 0a 19 0a fa 0a 00 0a 0a 0a 00  ................
  0110: 12 0c 05 0a 0d 0a 7d 0a 00 0a 09 0a 00 08 54 53  ......}.......TS
  0120: 53 4d 12 41 07 08 12 0d 05 0a 64 0b e8 03 0a 00  SM.A......d.....
  0130: 0a 00 0a 00 12 0d 05 0a 58 0b 6b 03 0a 00 0a 1e  ........X.k.....
  0140: 0a 00 12 0d 05 0a 4b 0b ee 02 0a 00 0a 1c 0a 00  ......K.........
  0150: 12 0d 05 0a 3f 0b 71 02 0a 00 0a 1a 0a 00 12 0d  ....?.q.........
  0160: 05 0a 32 0b f4 01 0a 00 0a 18 0a 00 12 0d 05 0a  ..2.............
  0170: 26 0b 77 01 0a 00 0a 16 0a 00 12 0c 05 0a 19 0a  &.w.............
  0180: fa 0a 00 0a 14 0a 00 12 0c 05 0a 0d 0a 7d 0a 00  .............}..
  0190: 0a 12 0a 00 08 54 53 53 46 0a 00 14 43 08 5f 54  .....TSSF...C._T
  01a0: 53 53 00 a0 47 06 90 92 54 53 53 46 5b 12 5f 50  SS..G...TSSF[._P
  01b0: 53 53 00 70 5f 50 53 53 60 70 87 60 61 76 61 70  SS.p_PSS`p.`avap
  01c0: 83 88 83 88 60 61 00 0a 01 00 62 70 0a 00 63 a2  ....`a....bp..c.
  01d0: 35 95 63 87 54 53 53 49 70 78 77 62 74 0a 08 63  5.c.TSSIpxwbt..c
  01e0: 00 00 0a 08 00 00 64 70 64 88 83 88 54 53 53 49  ......dpd...TSSI
  01f0: 63 00 0a 01 00 70 64 88 83 88 54 53 53 4d 63 00  c....pd...TSSMc.
  0200: 0a 01 00 75 63 70 ff 54 53 53 46 a0 0e 7b 50 44  ...ucp.TSSF..{PD
  0210: 43 30 0a 04 00 a4 54 53 53 4d a4 54 53 53 49 14  C0....TSSM.TSSI.
  0220: 3f 5f 54 53 44 00 a0 27 90 7b 43 46 47 44 0c 00  ?_TSD..'.{CFGD..
  0230: 00 00 01 00 92 7b 50 44 43 30 0a 04 00 a4 12 0f  .....{PDC0......
  0240: 01 12 0c 05 0a 05 0a 00 0a 00 0a fd 0a 02 a4 12  ................
  0250: 0f 01 12 0c 05 0a 05 0a 00 0a 00 0a fc 0a 01     ...............

SSDT @ 0xbff5a0c9
  0000: 53 53 44 54 a6 00 00 00 01 52 50 6d 52 65 66 00  SSDT.....RPmRef.
  0010: 43 70 75 37 54 73 74 00 00 30 00 00 49 4e 54 4c  Cpu7Tst..0..INTL
  0020: 28 02 05 20 10 41 08 5c 2e 5f 50 52 5f 43 50 55  (.. .A.\._PR_CPU
  0030: 37 08 5f 54 50 43 0a 00 14 16 5f 50 54 43 00 a4  7._TPC...._PTC..
  0040: 5c 2f 03 5f 50 52 5f 43 50 55 30 5f 50 54 43 14  \/._PR_CPU0_PTC.
  0050: 16 5f 54 53 53 00 a4 5c 2f 03 5f 50 52 5f 43 50  ._TSS..\/._PR_CP
  0060: 55 30 5f 54 53 53 14 3f 5f 54 53 44 00 a0 27 90  U0_TSS.?_TSD..'.
  0070: 7b 43 46 47 44 0c 00 00 00 01 00 92 7b 50 44 43  {CFGD.......{PDC
  0080: 37 0a 04 00 a4 12 0f 01 12 0c 05 0a 05 0a 00 0a  7...............
  0090: 03 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a 05 0a 00  ................
  00a0: 0a 07 0a fc 0a 01                                ......

SSDT @ 0xbff5a023
  0000: 53 53 44 54 a6 00 00 00 01 56 50 6d 52 65 66 00  SSDT.....VPmRef.
  0010: 43 70 75 36 54 73 74 00 00 30 00 00 49 4e 54 4c  Cpu6Tst..0..INTL
  0020: 28 02 05 20 10 41 08 5c 2e 5f 50 52 5f 43 50 55  (.. .A.\._PR_CPU
  0030: 36 08 5f 54 50 43 0a 00 14 16 5f 50 54 43 00 a4  6._TPC...._PTC..
  0040: 5c 2f 03 5f 50 52 5f 43 50 55 30 5f 50 54 43 14  \/._PR_CPU0_PTC.
  0050: 16 5f 54 53 53 00 a4 5c 2f 03 5f 50 52 5f 43 50  ._TSS..\/._PR_CP
  0060: 55 30 5f 54 53 53 14 3f 5f 54 53 44 00 a0 27 90  U0_TSS.?_TSD..'.
  0070: 7b 43 46 47 44 0c 00 00 00 01 00 92 7b 50 44 43  {CFGD.......{PDC
  0080: 36 0a 04 00 a4 12 0f 01 12 0c 05 0a 05 0a 00 0a  6...............
  0090: 03 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a 05 0a 00  ................
  00a0: 0a 06 0a fc 0a 01                                ......

SSDT @ 0xbff59f7d
  0000: 53 53 44 54 a6 00 00 00 01 5b 50 6d 52 65 66 00  SSDT.....[PmRef.
  0010: 43 70 75 35 54 73 74 00 00 30 00 00 49 4e 54 4c  Cpu5Tst..0..INTL
  0020: 28 02 05 20 10 41 08 5c 2e 5f 50 52 5f 43 50 55  (.. .A.\._PR_CPU
  0030: 35 08 5f 54 50 43 0a 00 14 16 5f 50 54 43 00 a4  5._TPC...._PTC..
  0040: 5c 2f 03 5f 50 52 5f 43 50 55 30 5f 50 54 43 14  \/._PR_CPU0_PTC.
  0050: 16 5f 54 53 53 00 a4 5c 2f 03 5f 50 52 5f 43 50  ._TSS..\/._PR_CP
  0060: 55 30 5f 54 53 53 14 3f 5f 54 53 44 00 a0 27 90  U0_TSS.?_TSD..'.
  0070: 7b 43 46 47 44 0c 00 00 00 01 00 92 7b 50 44 43  {CFGD.......{PDC
  0080: 35 0a 04 00 a4 12 0f 01 12 0c 05 0a 05 0a 00 0a  5...............
  0090: 02 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a 05 0a 00  ................
  00a0: 0a 05 0a fc 0a 01                                ......

SSDT @ 0xbff59ed7
  0000: 53 53 44 54 a6 00 00 00 01 5f 50 6d 52 65 66 00  SSDT....._PmRef.
  0010: 43 70 75 34 54 73 74 00 00 30 00 00 49 4e 54 4c  Cpu4Tst..0..INTL
  0020: 28 02 05 20 10 41 08 5c 2e 5f 50 52 5f 43 50 55  (.. .A.\._PR_CPU
  0030: 34 08 5f 54 50 43 0a 00 14 16 5f 50 54 43 00 a4  4._TPC...._PTC..
  0040: 5c 2f 03 5f 50 52 5f 43 50 55 30 5f 50 54 43 14  \/._PR_CPU0_PTC.
  0050: 16 5f 54 53 53 00 a4 5c 2f 03 5f 50 52 5f 43 50  ._TSS..\/._PR_CP
  0060: 55 30 5f 54 53 53 14 3f 5f 54 53 44 00 a0 27 90  U0_TSS.?_TSD..'.
  0070: 7b 43 46 47 44 0c 00 00 00 01 00 92 7b 50 44 43  {CFGD.......{PDC
  0080: 34 0a 04 00 a4 12 0f 01 12 0c 05 0a 05 0a 00 0a  4...............
  0090: 02 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a 05 0a 00  ................
  00a0: 0a 04 0a fc 0a 01                                ......

SSDT @ 0xbff59e31
  0000: 53 53 44 54 a6 00 00 00 01 64 50 6d 52 65 66 00  SSDT.....dPmRef.
  0010: 43 70 75 33 54 73 74 00 00 30 00 00 49 4e 54 4c  Cpu3Tst..0..INTL
  0020: 28 02 05 20 10 41 08 5c 2e 5f 50 52 5f 43 50 55  (.. .A.\._PR_CPU
  0030: 33 08 5f 54 50 43 0a 00 14 16 5f 50 54 43 00 a4  3._TPC...._PTC..
  0040: 5c 2f 03 5f 50 52 5f 43 50 55 30 5f 50 54 43 14  \/._PR_CPU0_PTC.
  0050: 16 5f 54 53 53 00 a4 5c 2f 03 5f 50 52 5f 43 50  ._TSS..\/._PR_CP
  0060: 55 30 5f 54 53 53 14 3f 5f 54 53 44 00 a0 27 90  U0_TSS.?_TSD..'.
  0070: 7b 43 46 47 44 0c 00 00 00 01 00 92 7b 50 44 43  {CFGD.......{PDC
  0080: 33 0a 04 00 a4 12 0f 01 12 0c 05 0a 05 0a 00 0a  3...............
  0090: 01 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a 05 0a 00  ................
  00a0: 0a 03 0a fc 0a 01                                ......

SSDT @ 0xbff59d8b
  0000: 53 53 44 54 a6 00 00 00 01 68 50 6d 52 65 66 00  SSDT.....hPmRef.
  0010: 43 70 75 32 54 73 74 00 00 30 00 00 49 4e 54 4c  Cpu2Tst..0..INTL
  0020: 28 02 05 20 10 41 08 5c 2e 5f 50 52 5f 43 50 55  (.. .A.\._PR_CPU
  0030: 32 08 5f 54 50 43 0a 00 14 16 5f 50 54 43 00 a4  2._TPC...._PTC..
  0040: 5c 2f 03 5f 50 52 5f 43 50 55 30 5f 50 54 43 14  \/._PR_CPU0_PTC.
  0050: 16 5f 54 53 53 00 a4 5c 2f 03 5f 50 52 5f 43 50  ._TSS..\/._PR_CP
  0060: 55 30 5f 54 53 53 14 3f 5f 54 53 44 00 a0 27 90  U0_TSS.?_TSD..'.
  0070: 7b 43 46 47 44 0c 00 00 00 01 00 92 7b 50 44 43  {CFGD.......{PDC
  0080: 32 0a 04 00 a4 12 0f 01 12 0c 05 0a 05 0a 00 0a  2...............
  0090: 01 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a 05 0a 00  ................
  00a0: 0a 02 0a fc 0a 01                                ......

SSDT @ 0xbff59ce5
  0000: 53 53 44 54 a6 00 00 00 01 6d 50 6d 52 65 66 00  SSDT.....mPmRef.
  0010: 43 70 75 31 54 73 74 00 00 30 00 00 49 4e 54 4c  Cpu1Tst..0..INTL
  0020: 28 02 05 20 10 41 08 5c 2e 5f 50 52 5f 43 50 55  (.. .A.\._PR_CPU
  0030: 31 08 5f 54 50 43 0a 00 14 16 5f 50 54 43 00 a4  1._TPC...._PTC..
  0040: 5c 2f 03 5f 50 52 5f 43 50 55 30 5f 50 54 43 14  \/._PR_CPU0_PTC.
  0050: 16 5f 54 53 53 00 a4 5c 2f 03 5f 50 52 5f 43 50  ._TSS..\/._PR_CP
  0060: 55 30 5f 54 53 53 14 3f 5f 54 53 44 00 a0 27 90  U0_TSS.?_TSD..'.
  0070: 7b 43 46 47 44 0c 00 00 00 01 00 92 7b 50 44 43  {CFGD.......{PDC
  0080: 31 0a 04 00 a4 12 0f 01 12 0c 05 0a 05 0a 00 0a  1...............
  0090: 00 0a fd 0a 02 a4 12 0f 01 12 0c 05 0a 05 0a 00  ................
  00a0: 0a 01 0a fc 0a 01                                ......

SSDT @ 0xbff588e0
  0000: 53 53 44 54 05 14 00 00 01 18 50 6d 52 65 66 00  SSDT......PmRef.
  0010: 43 70 75 50 6d 00 00 00 00 30 00 00 49 4e 54 4c  CpuPm....0..INTL
  0020: 28 02 05 20 10 47 1b 5c 00 08 53 53 44 54 12 43  (.. .G.\..SSDT.C
  0030: 14 30 0d 43 50 55 30 49 53 54 20 00 0c 89 ac f5  .0.CPU0IST .....
  0040: bf 0c dd 01 00 00 0d 43 50 55 31 49 53 54 20 00  .......CPU1IST .
  0050: 0c 66 ae f5 bf 0c 6e 01 00 00 0d 43 50 55 30 43  .f....n....CPU0C
  0060: 53 54 20 00 0c ce a3 f5 bf 0c 18 05 00 00 0d 43  ST ............C
  0070: 50 55 31 43 53 54 20 00 0c e6 a8 f5 bf 0c 85 00  PU1CST .........
  0080: 00 00 0d 43 50 55 32 49 53 54 20 00 0c d4 af f5  ...CPU2IST .....
  0090: bf 0c 6e 01 00 00 0d 43 50 55 33 49 53 54 20 00  ..n....CPU3IST .
  00a0: 0c 42 b1 f5 bf 0c 6e 01 00 00 0d 43 50 55 32 43  .B....n....CPU2C
  00b0: 53 54 20 00 0c 6b a9 f5 bf 0c 85 00 00 00 0d 43  ST ..k.........C
  00c0: 50 55 33 43 53 54 20 00 0c f0 a9 f5 bf 0c 85 00  PU3CST .........
  00d0: 00 00 0d 43 50 55 34 49 53 54 20 00 0c b0 b2 f5  ...CPU4IST .....
  00e0: bf 0c 6e 01 00 00 0d 43 50 55 35 49 53 54 20 00  ..n....CPU5IST .
  00f0: 0c 1e b4 f5 bf 0c 6e 01 00 00 0d 43 50 55 34 43  ......n....CPU4C
  0100: 53 54 20 00 0c 75 aa f5 bf 0c 85 00 00 00 0d 43  ST ..u.........C
  0110: 50 55 35 43 53 54 20 00 0c fa aa f5 bf 0c 85 00  PU5CST .........
  0120: 00 00 0d 43 50 55 36 49 53 54 20 00 0c 8c b5 f5  ...CPU6IST .....
  0130: bf 0c 6e 01 00 00 0d 43 50 55 37 49 53 54 20 00  ..n....CPU7IST .
  0140: 0c fa b6 f5 bf 0c 6e 01 00 00 0d 43 50 55 36 43  ......n....CPU6C
  0150: 53 54 20 00 0c 7f ab f5 bf 0c 85 00 00 00 0d 43  ST ............C
  0160: 50 55 37 43 53 54 20 00 0c 04 ac f5 bf 0c 85 00  PU7CST .........
  0170: 00 00 08 43 46 47 44 0c 71 08 23 19 08 5c 50 44  ...CFGD.q.#..\PD
  0180: 43 30 0c 00 00 00 80 08 5c 50 44 43 31 0c 00 00  C0......\PDC1...
  0190: 00 80 08 5c 50 44 43 32 0c 00 00 00 80 08 5c 50  ...\PDC2......\P
  01a0: 44 43 33 0c 00 00 00 80 08 5c 50 44 43 34 0c 00  DC3......\PDC4..
  01b0: 00 00 80 08 5c 50 44 43 35 0c 00 00 00 80 08 5c  ....\PDC5......\
  01c0: 50 44 43 36 0c 00 00 00 80 08 5c 50 44 43 37 0c  PDC6......\PDC7.
  01d0: 00 00 00 80 08 5c 53 44 54 4c 0a 00 10 40 29 5c  .....\SDTL...@)\
  01e0: 2e 5f 50 52 5f 43 50 55 30 08 48 49 30 5f 0a 00  ._PR_CPU0.HI0_..
  01f0: 08 48 43 30 5f 0a 00 14 48 06 5f 50 44 43 01 8a  .HC0_...H._PDC..
  0200: 68 0a 00 52 45 56 53 8a 68 0a 04 53 49 5a 45 70  h..REVS.h..SIZEp
  0210: 87 68 60 70 74 60 0a 08 00 61 5b 13 68 0a 40 77  .h`pt`...a[.h.@w
  0220: 61 0a 08 00 54 45 4d 50 08 53 54 53 30 11 07 0a  a...TEMP.STS0...
  0230: 04 00 00 00 00 73 53 54 53 30 54 45 4d 50 62 5f  .....sSTS0TEMPb_
  0240: 4f 53 43 11 13 0a 10 16 a6 77 40 0c 29 be 47 9e  OSC......w@.).G.
  0250: bd d8 70 58 71 39 53 52 45 56 53 53 49 5a 45 62  ..pXq9SREVSSIZEb
  0260: 14 4c 20 5f 4f 53 43 04 8a 6b 0a 00 53 54 53 30  .L _OSC..k..STS0
  0270: 8a 6b 0a 04 43 41 50 30 8a 68 0a 00 49 49 44 30  .k..CAP0.h..IID0
  0280: 8a 68 0a 04 49 49 44 31 8a 68 0a 08 49 49 44 32  .h..IID1.h..IID2
  0290: 8a 68 0a 0c 49 49 44 33 08 55 49 44 30 11 13 0a  .h..IID3.UID0...
  02a0: 10 16 a6 77 40 0c 29 be 47 9e bd d8 70 58 71 39  ...w@.).G...pXq9
  02b0: 53 8a 55 49 44 30 0a 00 45 49 44 30 8a 55 49 44  S.UID0..EID0.UID
  02c0: 30 0a 04 45 49 44 31 8a 55 49 44 30 0a 08 45 49  0..EID1.UID0..EI
  02d0: 44 32 8a 55 49 44 30 0a 0c 45 49 44 33 a0 32 92  D2.UID0..EID3.2.
  02e0: 90 90 93 49 49 44 30 45 49 44 30 93 49 49 44 31  ...IID0EID0.IID1
  02f0: 45 49 44 31 90 93 49 49 44 32 45 49 44 32 93 49  EID1..IID2EID2.I
  0300: 49 44 33 45 49 44 33 70 0a 06 53 54 53 30 a4 6b  ID3EID3p..STS0.k
  0310: a0 0f 92 93 69 0a 01 70 0a 0a 53 54 53 30 a4 6b  ....i..p..STS0.k
  0320: 7d 7b 50 44 43 30 0c ff ff ff 7f 00 43 41 50 30  }{PDC0......CAP0
  0330: 50 44 43 30 a0 43 08 7b 43 46 47 44 0a 01 00 a0  PDC0.C.{CFGD....
  0340: 48 07 90 90 7d 7d 7b 43 46 47 44 0c 00 00 00 08  H...}}{CFGD.....
  0350: 00 7b 43 46 47 44 0c 00 00 00 04 00 00 7d 7b 43  .{CFGD.......}{C
  0360: 46 47 44 0c 00 00 00 01 00 7b 43 46 47 44 0c 00  FGD......{CFGD..
  0370: 00 00 02 00 00 00 93 7b 50 44 43 30 0a 09 00 0a  .......{PDC0....
  0380: 09 92 7b 53 44 54 4c 0a 01 00 7d 53 44 54 4c 0a  ..{SDTL...}SDTL.
  0390: 01 53 44 54 4c 5b 80 49 53 54 30 00 83 88 53 53  .SDTL[.IST0...SS
  03a0: 44 54 0a 01 00 83 88 53 53 44 54 0a 02 00 5b 20  DT.....SSDT...[
  03b0: 49 53 54 30 48 49 30 5f a0 42 0b 7b 43 46 47 44  IST0HI0_.B.{CFGD
  03c0: 0a f0 00 a0 48 05 90 7b 43 46 47 44 0c 00 00 00  ....H..{CFGD....
  03d0: 01 00 7b 50 44 43 30 0a 10 00 70 0a 49 5c 2f 04  ..{PDC0...p.I\/.
  03e0: 5f 53 42 5f 50 43 49 30 4c 50 43 30 42 43 4d 44  _SB_PCI0LPC0BCMD
  03f0: 70 0a 00 5c 2f 04 5f 53 42 5f 50 43 49 30 4c 50  p..\/._SB_PCI0LP
  0400: 43 30 44 49 44 5f 70 0a 00 5c 2f 04 5f 53 42 5f  C0DID_p..\/._SB_
  0410: 50 43 49 30 4c 50 43 30 53 4d 49 43 a0 4e 04 90  PCI0LPC0SMIC.N..
  0420: 90 7b 43 46 47 44 0c 00 00 00 01 00 7b 50 44 43  .{CFGD......{PDC
  0430: 30 0a 18 00 92 7b 53 44 54 4c 0a 02 00 7d 53 44  0....{SDTL...}SD
  0440: 54 4c 0a 02 53 44 54 4c 5b 80 43 53 54 30 00 83  TL..SDTL[.CST0..
  0450: 88 53 53 44 54 0a 07 00 83 88 53 53 44 54 0a 08  .SSDT.....SSDT..
  0460: 00 5b 20 43 53 54 30 48 43 30 5f a4 6b 10 47 23  .[ CST0HC0_.k.G#
  0470: 5c 2e 5f 50 52 5f 43 50 55 31 08 48 49 31 5f 0a  \._PR_CPU1.HI1_.
  0480: 00 08 48 43 31 5f 0a 00 14 48 06 5f 50 44 43 01  ..HC1_...H._PDC.
  0490: 8a 68 0a 00 52 45 56 53 8a 68 0a 04 53 49 5a 45  .h..REVS.h..SIZE
  04a0: 70 87 68 60 70 74 60 0a 08 00 61 5b 13 68 0a 40  p.h`pt`...a[.h.@
  04b0: 77 61 0a 08 00 54 45 4d 50 08 53 54 53 31 11 07  wa...TEMP.STS1..
  04c0: 0a 04 00 00 00 00 73 53 54 53 31 54 45 4d 50 62  ......sSTS1TEMPb
  04d0: 5f 4f 53 43 11 13 0a 10 16 a6 77 40 0c 29 be 47  _OSC......w@.).G
  04e0: 9e bd d8 70 58 71 39 53 52 45 56 53 53 49 5a 45  ...pXq9SREVSSIZE
  04f0: 62 14 43 1b 5f 4f 53 43 04 8a 6b 0a 00 53 54 53  b.C._OSC..k..STS
  0500: 31 8a 6b 0a 04 43 41 50 31 8a 68 0a 00 49 49 44  1.k..CAP1.h..IID
  0510: 30 8a 68 0a 04 49 49 44 31 8a 68 0a 08 49 49 44  0.h..IID1.h..IID
  0520: 32 8a 68 0a 0c 49 49 44 33 08 55 49 44 31 11 13  2.h..IID3.UID1..
  0530: 0a 10 16 a6 77 40 0c 29 be 47 9e bd d8 70 58 71  ....w@.).G...pXq
  0540: 39 53 8a 55 49 44 31 0a 00 45 49 44 30 8a 55 49  9S.UID1..EID0.UI
  0550: 44 31 0a 04 45 49 44 31 8a 55 49 44 31 0a 08 45  D1..EID1.UID1..E
  0560: 49 44 32 8a 55 49 44 31 0a 0c 45 49 44 33 a0 32  ID2.UID1..EID3.2
  0570: 92 90 90 93 49 49 44 30 45 49 44 30 93 49 49 44  ....IID0EID0.IID
  0580: 31 45 49 44 31 90 93 49 49 44 32 45 49 44 32 93  1EID1..IID2EID2.
  0590: 49 49 44 33 45 49 44 33 70 0a 06 53 54 53 31 a4  IID3EID3p..STS1.
  05a0: 6b a0 0f 92 93 69 0a 01 70 0a 0a 53 54 53 31 a4  k....i..p..STS1.
  05b0: 6b 7d 7b 50 44 43 31 0c ff ff ff 7f 00 43 41 50  k}{PDC1......CAP
  05c0: 31 50 44 43 31 a0 43 08 7b 43 46 47 44 0a 01 00  1PDC1.C.{CFGD...
  05d0: a0 48 07 90 90 7d 7d 7b 43 46 47 44 0c 00 00 00  .H...}}{CFGD....
  05e0: 08 00 7b 43 46 47 44 0c 00 00 00 04 00 00 7d 7b  ..{CFGD.......}{
  05f0: 43 46 47 44 0c 00 00 00 01 00 7b 43 46 47 44 0c  CFGD......{CFGD.
  0600: 00 00 00 02 00 00 00 93 7b 50 44 43 31 0a 09 00  ........{PDC1...
  0610: 0a 09 92 7b 53 44 54 4c 0a 10 00 7d 53 44 54 4c  ...{SDTL...}SDTL
  0620: 0a 10 53 44 54 4c 5b 80 49 53 54 31 00 83 88 53  ..SDTL[.IST1...S
  0630: 53 44 54 0a 04 00 83 88 53 53 44 54 0a 05 00 5b  SDT.....SSDT...[
  0640: 20 49 53 54 31 48 49 31 5f a0 49 05 7b 43 46 47   IST1HI1_.I.{CFG
  0650: 44 0a f0 00 a0 4e 04 90 90 7b 43 46 47 44 0c 00  D....N...{CFGD..
  0660: 00 00 01 00 7b 50 44 43 31 0a 18 00 92 7b 53 44  ....{PDC1....{SD
  0670: 54 4c 0a 20 00 7d 53 44 54 4c 0a 20 53 44 54 4c  TL. .}SDTL. SDTL
  0680: 5b 80 43 53 54 31 00 83 88 53 53 44 54 0a 0a 00  [.CST1...SSDT...
  0690: 83 88 53 53 44 54 0a 0b 00 5b 20 43 53 54 31 48  ..SSDT...[ CST1H
  06a0: 43 31 5f a4 6b 10 47 23 5c 2e 5f 50 52 5f 43 50  C1_.k.G#\._PR_CP
  06b0: 55 32 08 48 49 32 5f 0a 00 08 48 43 32 5f 0a 00  U2.HI2_...HC2_..
  06c0: 14 48 06 5f 50 44 43 01 8a 68 0a 00 52 45 56 53  .H._PDC..h..REVS
  06d0: 8a 68 0a 04 53 49 5a 45 70 87 68 60 70 74 60 0a  .h..SIZEp.h`pt`.
  06e0: 08 00 61 5b 13 68 0a 40 77 61 0a 08 00 54 45 4d  ..a[.h.@wa...TEM
  06f0: 50 08 53 54 53 32 11 07 0a 04 00 00 00 00 73 53  P.STS2........sS
  0700: 54 53 32 54 45 4d 50 62 5f 4f 53 43 11 13 0a 10  TS2TEMPb_OSC....
  0710: 16 a6 77 40 0c 29 be 47 9e bd d8 70 58 71 39 53  ..w@.).G...pXq9S
  0720: 52 45 56 53 53 49 5a 45 62 14 43 1b 5f 4f 53 43  REVSSIZEb.C._OSC
  0730: 04 8a 6b 0a 00 53 54 53 32 8a 6b 0a 04 43 41 50  ..k..STS2.k..CAP
  0740: 32 8a 68 0a 00 49 49 44 30 8a 68 0a 04 49 49 44  2.h..IID0.h..IID
  0750: 31 8a 68 0a 08 49 49 44 32 8a 68 0a 0c 49 49 44  1.h..IID2.h..IID
  0760: 33 08 55 49 44 31 11 13 0a 10 16 a6 77 40 0c 29  3.UID1......w@.)
  0770: be 47 9e bd d8 70 58 71 39 53 8a 55 49 44 31 0a  .G...pXq9S.UID1.
  0780: 00 45 49 44 30 8a 55 49 44 31 0a 04 45 49 44 31  .EID0.UID1..EID1
  0790: 8a 55 49 44 31 0a 08 45 49 44 32 8a 55 49 44 31  .UID1..EID2.UID1
  07a0: 0a 0c 45 49 44 33 a0 32 92 90 90 93 49 49 44 30  ..EID3.2....IID0
  07b0: 45 49 44 30 93 49 49 44 31 45 49 44 31 90 93 49  EID0.IID1EID1..I
  07c0: 49 44 32 45 49 44 32 93 49 49 44 33 45 49 44 33  ID2EID2.IID3EID3
  07d0: 70 0a 06 53 54 53 32 a4 6b a0 0f 92 93 69 0a 01  p..STS2.k....i..
  07e0: 70 0a 0a 53 54 53 32 a4 6b 7d 7b 50 44 43 32 0c  p..STS2.k}{PDC2.
  07f0: ff ff ff 7f 00 43 41 50 32 50 44 43 32 a0 43 08  .....CAP2PDC2.C.
  0800: 7b 43 46 47 44 0a 01 00 a0 48 07 90 90 7d 7d 7b  {CFGD....H...}}{
  0810: 43 46 47 44 0c 00 00 00 08 00 7b 43 46 47 44 0c  CFGD......{CFGD.
  0820: 00 00 00 04 00 00 7d 7b 43 46 47 44 0c 00 00 00  ......}{CFGD....
  0830: 01 00 7b 43 46 47 44 0c 00 00 00 02 00 00 00 93  ..{CFGD.........
  0840: 7b 50 44 43 32 0a 09 00 0a 09 92 7b 53 44 54 4c  {PDC2......{SDTL
  0850: 0a 04 00 7d 53 44 54 4c 0a 04 53 44 54 4c 5b 80  ...}SDTL..SDTL[.
  0860: 49 53 54 32 00 83 88 53 53 44 54 0a 0d 00 83 88  IST2...SSDT.....
  0870: 53 53 44 54 0a 0e 00 5b 20 49 53 54 32 48 49 32  SSDT...[ IST2HI2
  0880: 5f a0 49 05 7b 43 46 47 44 0a f0 00 a0 4e 04 90  _.I.{CFGD....N..
  0890: 90 7b 43 46 47 44 0c 00 00 00 01 00 7b 50 44 43  .{CFGD......{PDC
  08a0: 32 0a 18 00 92 7b 53 44 54 4c 0a 08 00 7d 53 44  2....{SDTL...}SD
  08b0: 54 4c 0a 08 53 44 54 4c 5b 80 43 53 54 32 00 83  TL..SDTL[.CST2..
  08c0: 88 53 53 44 54 0a 13 00 83 88 53 53 44 54 0a 14  .SSDT.....SSDT..
  08d0: 00 5b 20 43 53 54 32 48 43 32 5f a4 6b 10 47 23  .[ CST2HC2_.k.G#
  08e0: 5c 2e 5f 50 52 5f 43 50 55 33 08 48 49 33 5f 0a  \._PR_CPU3.HI3_.
  08f0: 00 08 48 43 33 5f 0a 00 14 48 06 5f 50 44 43 01  ..HC3_...H._PDC.
  0900: 8a 68 0a 00 52 45 56 53 8a 68 0a 04 53 49 5a 45  .h..REVS.h..SIZE
  0910: 70 87 68 60 70 74 60 0a 08 00 61 5b 13 68 0a 40  p.h`pt`...a[.h.@
  0920: 77 61 0a 08 00 54 45 4d 50 08 53 54 53 33 11 07  wa...TEMP.STS3..
  0930: 0a 04 00 00 00 00 73 53 54 53 33 54 45 4d 50 62  ......sSTS3TEMPb
  0940: 5f 4f 53 43 11 13 0a 10 16 a6 77 40 0c 29 be 47  _OSC......w@.).G
  0950: 9e bd d8 70 58 71 39 53 52 45 56 53 53 49 5a 45  ...pXq9SREVSSIZE
  0960: 62 14 43 1b 5f 4f 53 43 04 8a 6b 0a 00 53 54 53  b.C._OSC..k..STS
  0970: 33 8a 6b 0a 04 43 41 50 33 8a 68 0a 00 49 49 44  3.k..CAP3.h..IID
  0980: 30 8a 68 0a 04 49 49 44 31 8a 68 0a 08 49 49 44  0.h..IID1.h..IID
  0990: 32 8a 68 0a 0c 49 49 44 33 08 55 49 44 31 11 13  2.h..IID3.UID1..
  09a0: 0a 10 16 a6 77 40 0c 29 be 47 9e bd d8 70 58 71  ....w@.).G...pXq
  09b0: 39 53 8a 55 49 44 31 0a 00 45 49 44 30 8a 55 49  9S.UID1..EID0.UI
  09c0: 44 31 0a 04 45 49 44 31 8a 55 49 44 31 0a 08 45  D1..EID1.UID1..E
  09d0: 49 44 32 8a 55 49 44 31 0a 0c 45 49 44 33 a0 32  ID2.UID1..EID3.2
  09e0: 92 90 90 93 49 49 44 30 45 49 44 30 93 49 49 44  ....IID0EID0.IID
  09f0: 31 45 49 44 31 90 93 49 49 44 32 45 49 44 32 93  1EID1..IID2EID2.
  0a00: 49 49 44 33 45 49 44 33 70 0a 06 53 54 53 33 a4  IID3EID3p..STS3.
  0a10: 6b a0 0f 92 93 69 0a 01 70 0a 0a 53 54 53 33 a4  k....i..p..STS3.
  0a20: 6b 7d 7b 50 44 43 33 0c ff ff ff 7f 00 43 41 50  k}{PDC3......CAP
  0a30: 33 50 44 43 33 a0 43 08 7b 43 46 47 44 0a 01 00  3PDC3.C.{CFGD...
  0a40: a0 48 07 90 90 7d 7d 7b 43 46 47 44 0c 00 00 00  .H...}}{CFGD....
  0a50: 08 00 7b 43 46 47 44 0c 00 00 00 04 00 00 7d 7b  ..{CFGD.......}{
  0a60: 43 46 47 44 0c 00 00 00 01 00 7b 43 46 47 44 0c  CFGD......{CFGD.
  0a70: 00 00 00 02 00 00 00 93 7b 50 44 43 33 0a 09 00  ........{PDC3...
  0a80: 0a 09 92 7b 53 44 54 4c 0a 40 00 7d 53 44 54 4c  ...{SDTL.@.}SDTL
  0a90: 0a 40 53 44 54 4c 5b 80 49 53 54 33 00 83 88 53  .@SDTL[.IST3...S
  0aa0: 53 44 54 0a 10 00 83 88 53 53 44 54 0a 11 00 5b  SDT.....SSDT...[
  0ab0: 20 49 53 54 33 48 49 33 5f a0 49 05 7b 43 46 47   IST3HI3_.I.{CFG
  0ac0: 44 0a f0 00 a0 4e 04 90 90 7b 43 46 47 44 0c 00  D....N...{CFGD..
  0ad0: 00 00 01 00 7b 50 44 43 33 0a 18 00 92 7b 53 44  ....{PDC3....{SD
  0ae0: 54 4c 0a 80 00 7d 53 44 54 4c 0a 80 53 44 54 4c  TL...}SDTL..SDTL
  0af0: 5b 80 43 53 54 33 00 83 88 53 53 44 54 0a 16 00  [.CST3...SSDT...
  0b00: 83 88 53 53 44 54 0a 17 00 5b 20 43 53 54 33 48  ..SSDT...[ CST3H
  0b10: 43 33 5f a4 6b 10 4b 23 5c 2e 5f 50 52 5f 43 50  C3_.k.K#\._PR_CP
  0b20: 55 34 08 48 49 34 5f 0a 00 08 48 43 34 5f 0a 00  U4.HI4_...HC4_..
  0b30: 14 48 06 5f 50 44 43 01 8a 68 0a 00 52 45 56 53  .H._PDC..h..REVS
  0b40: 8a 68 0a 04 53 49 5a 45 70 87 68 60 70 74 60 0a  .h..SIZEp.h`pt`.
  0b50: 08 00 61 5b 13 68 0a 40 77 61 0a 08 00 54 45 4d  ..a[.h.@wa...TEM
  0b60: 50 08 53 54 53 34 11 07 0a 04 00 00 00 00 73 53  P.STS4........sS
  0b70: 54 53 34 54 45 4d 50 62 5f 4f 53 43 11 13 0a 10  TS4TEMPb_OSC....
  0b80: 16 a6 77 40 0c 29 be 47 9e bd d8 70 58 71 39 53  ..w@.).G...pXq9S
  0b90: 52 45 56 53 53 49 5a 45 62 14 47 1b 5f 4f 53 43  REVSSIZEb.G._OSC
  0ba0: 04 8a 6b 0a 00 53 54 53 34 8a 6b 0a 04 43 41 50  ..k..STS4.k..CAP
  0bb0: 34 8a 68 0a 00 49 49 44 30 8a 68 0a 04 49 49 44  4.h..IID0.h..IID
  0bc0: 31 8a 68 0a 08 49 49 44 32 8a 68 0a 0c 49 49 44  1.h..IID2.h..IID
  0bd0: 33 08 55 49 44 31 11 13 0a 10 16 a6 77 40 0c 29  3.UID1......w@.)
  0be0: be 47 9e bd d8 70 58 71 39 53 8a 55 49 44 31 0a  .G...pXq9S.UID1.
  0bf0: 00 45 49 44 30 8a 55 49 44 31 0a 04 45 49 44 31  .EID0.UID1..EID1
  0c00: 8a 55 49 44 31 0a 08 45 49 44 32 8a 55 49 44 31  .UID1..EID2.UID1
  0c10: 0a 0c 45 49 44 33 a0 32 92 90 90 93 49 49 44 30  ..EID3.2....IID0
  0c20: 45 49 44 30 93 49 49 44 31 45 49 44 31 90 93 49  EID0.IID1EID1..I
  0c30: 49 44 32 45 49 44 32 93 49 49 44 33 45 49 44 33  ID2EID2.IID3EID3
  0c40: 70 0a 06 53 54 53 34 a4 6b a0 0f 92 93 69 0a 01  p..STS4.k....i..
  0c50: 70 0a 0a 53 54 53 34 a4 6b 7d 7b 50 44 43 34 0c  p..STS4.k}{PDC4.
  0c60: ff ff ff 7f 00 43 41 50 34 50 44 43 34 a0 45 08  .....CAP4PDC4.E.
  0c70: 7b 43 46 47 44 0a 01 00 a0 4a 07 90 90 7d 7d 7b  {CFGD....J...}}{
  0c80: 43 46 47 44 0c 00 00 00 08 00 7b 43 46 47 44 0c  CFGD......{CFGD.
  0c90: 00 00 00 04 00 00 7d 7b 43 46 47 44 0c 00 00 00  ......}{CFGD....
  0ca0: 01 00 7b 43 46 47 44 0c 00 00 00 02 00 00 00 93  ..{CFGD.........
  0cb0: 7b 50 44 43 34 0a 09 00 0a 09 92 7b 53 44 54 4c  {PDC4......{SDTL
  0cc0: 0b 00 01 00 7d 53 44 54 4c 0b 00 01 53 44 54 4c  ....}SDTL...SDTL
  0cd0: 5b 80 49 53 54 34 00 83 88 53 53 44 54 0a 19 00  [.IST4...SSDT...
  0ce0: 83 88 53 53 44 54 0a 1a 00 5b 20 49 53 54 34 48  ..SSDT...[ IST4H
  0cf0: 49 34 5f a0 4b 05 7b 43 46 47 44 0a f0 00 a0 40  I4_.K.{CFGD....@
  0d00: 05 90 90 7b 43 46 47 44 0c 00 00 00 01 00 7b 50  ...{CFGD......{P
  0d10: 44 43 34 0a 18 00 92 7b 53 44 54 4c 0b 00 02 00  DC4....{SDTL....
  0d20: 7d 53 44 54 4c 0b 00 02 53 44 54 4c 5b 80 43 53  }SDTL...SDTL[.CS
  0d30: 54 34 00 83 88 53 53 44 54 0a 1f 00 83 88 53 53  T4...SSDT.....SS
  0d40: 44 54 0a 20 00 5b 20 43 53 54 34 48 43 34 5f a4  DT. .[ CST4HC4_.
  0d50: 6b 10 4b 23 5c 2e 5f 50 52 5f 43 50 55 35 08 48  k.K#\._PR_CPU5.H
  0d60: 49 35 5f 0a 00 08 48 43 35 5f 0a 00 14 48 06 5f  I5_...HC5_...H._
  0d70: 50 44 43 01 8a 68 0a 00 52 45 56 53 8a 68 0a 04  PDC..h..REVS.h..
  0d80: 53 49 5a 45 70 87 68 60 70 74 60 0a 08 00 61 5b  SIZEp.h`pt`...a[
  0d90: 13 68 0a 40 77 61 0a 08 00 54 45 4d 50 08 53 54  .h.@wa...TEMP.ST
  0da0: 53 35 11 07 0a 04 00 00 00 00 73 53 54 53 35 54  S5........sSTS5T
  0db0: 45 4d 50 62 5f 4f 53 43 11 13 0a 10 16 a6 77 40  EMPb_OSC......w@
  0dc0: 0c 29 be 47 9e bd d8 70 58 71 39 53 52 45 56 53  .).G...pXq9SREVS
  0dd0: 53 49 5a 45 62 14 47 1b 5f 4f 53 43 04 8a 6b 0a  SIZEb.G._OSC..k.
  0de0: 00 53 54 53 35 8a 6b 0a 04 43 41 50 35 8a 68 0a  .STS5.k..CAP5.h.
  0df0: 00 49 49 44 30 8a 68 0a 04 49 49 44 31 8a 68 0a  .IID0.h..IID1.h.
  0e00: 08 49 49 44 32 8a 68 0a 0c 49 49 44 33 08 55 49  .IID2.h..IID3.UI
  0e10: 44 31 11 13 0a 10 16 a6 77 40 0c 29 be 47 9e bd  D1......w@.).G..
  0e20: d8 70 58 71 39 53 8a 55 49 44 31 0a 00 45 49 44  .pXq9S.UID1..EID
  0e30: 30 8a 55 49 44 31 0a 04 45 49 44 31 8a 55 49 44  0.UID1..EID1.UID
  0e40: 31 0a 08 45 49 44 32 8a 55 49 44 31 0a 0c 45 49  1..EID2.UID1..EI
  0e50: 44 33 a0 32 92 90 90 93 49 49 44 30 45 49 44 30  D3.2....IID0EID0
  0e60: 93 49 49 44 31 45 49 44 31 90 93 49 49 44 32 45  .IID1EID1..IID2E
  0e70: 49 44 32 93 49 49 44 33 45 49 44 33 70 0a 06 53  ID2.IID3EID3p..S
  0e80: 54 53 35 a4 6b a0 0f 92 93 69 0a 01 70 0a 0a 53  TS5.k....i..p..S
  0e90: 54 53 35 a4 6b 7d 7b 50 44 43 35 0c ff ff ff 7f  TS5.k}{PDC5.....
  0ea0: 00 43 41 50 35 50 44 43 35 a0 45 08 7b 43 46 47  .CAP5PDC5.E.{CFG
  0eb0: 44 0a 01 00 a0 4a 07 90 90 7d 7d 7b 43 46 47 44  D....J...}}{CFGD
  0ec0: 0c 00 00 00 08 00 7b 43 46 47 44 0c 00 00 00 04  ......{CFGD.....
  0ed0: 00 00 7d 7b 43 46 47 44 0c 00 00 00 01 00 7b 43  ..}{CFGD......{C
  0ee0: 46 47 44 0c 00 00 00 02 00 00 00 93 7b 50 44 43  FGD.........{PDC
  0ef0: 35 0a 09 00 0a 09 92 7b 53 44 54 4c 0b 00 04 00  5......{SDTL....
  0f00: 7d 53 44 54 4c 0b 00 04 53 44 54 4c 5b 80 49 53  }SDTL...SDTL[.IS
  0f10: 54 35 00 83 88 53 53 44 54 0a 1c 00 83 88 53 53  T5...SSDT.....SS
  0f20: 44 54 0a 1d 00 5b 20 49 53 54 35 48 49 35 5f a0  DT...[ IST5HI5_.
  0f30: 4b 05 7b 43 46 47 44 0a f0 00 a0 40 05 90 90 7b  K.{CFGD....@...{
  0f40: 43 46 47 44 0c 00 00 00 01 00 7b 50 44 43 35 0a  CFGD......{PDC5.
  0f50: 18 00 92 7b 53 44 54 4c 0b 00 08 00 7d 53 44 54  ...{SDTL....}SDT
  0f60: 4c 0b 00 08 53 44 54 4c 5b 80 43 53 54 35 00 83  L...SDTL[.CST5..
  0f70: 88 53 53 44 54 0a 22 00 83 88 53 53 44 54 0a 23  .SSDT."...SSDT.#
  0f80: 00 5b 20 43 53 54 35 48 43 35 5f a4 6b 10 4b 23  .[ CST5HC5_.k.K#
  0f90: 5c 2e 5f 50 52 5f 43 50 55 36 08 48 49 36 5f 0a  \._PR_CPU6.HI6_.
  0fa0: 00 08 48 43 36 5f 0a 00 14 48 06 5f 50 44 43 01  ..HC6_...H._PDC.
  0fb0: 8a 68 0a 00 52 45 56 53 8a 68 0a 04 53 49 5a 45  .h..REVS.h..SIZE
  0fc0: 70 87 68 60 70 74 60 0a 08 00 61 5b 13 68 0a 40  p.h`pt`...a[.h.@
  0fd0: 77 61 0a 08 00 54 45 4d 50 08 53 54 53 36 11 07  wa...TEMP.STS6..
  0fe0: 0a 04 00 00 00 00 73 53 54 53 36 54 45 4d 50 62  ......sSTS6TEMPb
  0ff0: 5f 4f 53 43 11 13 0a 10 16 a6 77 40 0c 29 be 47  _OSC......w@.).G
  1000: 9e bd d8 70 58 71 39 53 52 45 56 53 53 49 5a 45  ...pXq9SREVSSIZE
  1010: 62 14 47 1b 5f 4f 53 43 04 8a 6b 0a 00 53 54 53  b.G._OSC..k..STS
  1020: 36 8a 6b 0a 04 43 41 50 36 8a 68 0a 00 49 49 44  6.k..CAP6.h..IID
  1030: 30 8a 68 0a 04 49 49 44 31 8a 68 0a 08 49 49 44  0.h..IID1.h..IID
  1040: 32 8a 68 0a 0c 49 49 44 33 08 55 49 44 31 11 13  2.h..IID3.UID1..
  1050: 0a 10 16 a6 77 40 0c 29 be 47 9e bd d8 70 58 71  ....w@.).G...pXq
  1060: 39 53 8a 55 49 44 31 0a 00 45 49 44 30 8a 55 49  9S.UID1..EID0.UI
  1070: 44 31 0a 04 45 49 44 31 8a 55 49 44 31 0a 08 45  D1..EID1.UID1..E
  1080: 49 44 32 8a 55 49 44 31 0a 0c 45 49 44 33 a0 32  ID2.UID1..EID3.2
  1090: 92 90 90 93 49 49 44 30 45 49 44 30 93 49 49 44  ....IID0EID0.IID
  10a0: 31 45 49 44 31 90 93 49 49 44 32 45 49 44 32 93  1EID1..IID2EID2.
  10b0: 49 49 44 33 45 49 44 33 70 0a 06 53 54 53 36 a4  IID3EID3p..STS6.
  10c0: 6b a0 0f 92 93 69 0a 01 70 0a 0a 53 54 53 36 a4  k....i..p..STS6.
  10d0: 6b 7d 7b 50 44 43 36 0c ff ff ff 7f 00 43 41 50  k}{PDC6......CAP
  10e0: 36 50 44 43 36 a0 45 08 7b 43 46 47 44 0a 01 00  6PDC6.E.{CFGD...
  10f0: a0 4a 07 90 90 7d 7d 7b 43 46 47 44 0c 00 00 00  .J...}}{CFGD....
  1100: 08 00 7b 43 46 47 44 0c 00 00 00 04 00 00 7d 7b  ..{CFGD.......}{
  1110: 43 46 47 44 0c 00 00 00 01 00 7b 43 46 47 44 0c  CFGD......{CFGD.
  1120: 00 00 00 02 00 00 00 93 7b 50 44 43 36 0a 09 00  ........{PDC6...
  1130: 0a 09 92 7b 53 44 54 4c 0b 00 10 00 7d 53 44 54  ...{SDTL....}SDT
  1140: 4c 0b 00 10 53 44 54 4c 5b 80 49 53 54 36 00 83  L...SDTL[.IST6..
  1150: 88 53 53 44 54 0a 25 00 83 88 53 53 44 54 0a 26  .SSDT.%...SSDT.&
  1160: 00 5b 20 49 53 54 36 48 49 36 5f a0 4b 05 7b 43  .[ IST6HI6_.K.{C
  1170: 46 47 44 0a f0 00 a0 40 05 90 90 7b 43 46 47 44  FGD....@...{CFGD
  1180: 0c 00 00 00 01 00 7b 50 44 43 36 0a 18 00 92 7b  ......{PDC6....{
  1190: 53 44 54 4c 0b 00 20 00 7d 53 44 54 4c 0b 00 20  SDTL.. .}SDTL..
  11a0: 53 44 54 4c 5b 80 43 53 54 36 00 83 88 53 53 44  SDTL[.CST6...SSD
  11b0: 54 0a 2b 00 83 88 53 53 44 54 0a 2c 00 5b 20 43  T.+...SSDT.,.[ C
  11c0: 53 54 36 48 43 36 5f a4 6b 10 4b 23 5c 2e 5f 50  ST6HC6_.k.K#\._P
  11d0: 52 5f 43 50 55 37 08 48 49 37 5f 0a 00 08 48 43  R_CPU7.HI7_...HC
  11e0: 37 5f 0a 00 14 48 06 5f 50 44 43 01 8a 68 0a 00  7_...H._PDC..h..
  11f0: 52 45 56 53 8a 68 0a 04 53 49 5a 45 70 87 68 60  REVS.h..SIZEp.h`
  1200: 70 74 60 0a 08 00 61 5b 13 68 0a 40 77 61 0a 08  pt`...a[.h.@wa..
  1210: 00 54 45 4d 50 08 53 54 53 37 11 07 0a 04 00 00  .TEMP.STS7......
  1220: 00 00 73 53 54 53 37 54 45 4d 50 62 5f 4f 53 43  ..sSTS7TEMPb_OSC
  1230: 11 13 0a 10 16 a6 77 40 0c 29 be 47 9e bd d8 70  ......w@.).G...p
  1240: 58 71 39 53 52 45 56 53 53 49 5a 45 62 14 47 1b  Xq9SREVSSIZEb.G.
  1250: 5f 4f 53 43 04 8a 6b 0a 00 53 54 53 37 8a 6b 0a  _OSC..k..STS7.k.
  1260: 04 43 41 50 37 8a 68 0a 00 49 49 44 30 8a 68 0a  .CAP7.h..IID0.h.
  1270: 04 49 49 44 31 8a 68 0a 08 49 49 44 32 8a 68 0a  .IID1.h..IID2.h.
  1280: 0c 49 49 44 33 08 55 49 44 31 11 13 0a 10 16 a6  .IID3.UID1......
  1290: 77 40 0c 29 be 47 9e bd d8 70 58 71 39 53 8a 55  w@.).G...pXq9S.U
  12a0: 49 44 31 0a 00 45 49 44 30 8a 55 49 44 31 0a 04  ID1..EID0.UID1..
  12b0: 45 49 44 31 8a 55 49 44 31 0a 08 45 49 44 32 8a  EID1.UID1..EID2.
  12c0: 55 49 44 31 0a 0c 45 49 44 33 a0 32 92 90 90 93  UID1..EID3.2....
  12d0: 49 49 44 30 45 49 44 30 93 49 49 44 31 45 49 44  IID0EID0.IID1EID
  12e0: 31 90 93 49 49 44 32 45 49 44 32 93 49 49 44 33  1..IID2EID2.IID3
  12f0: 45 49 44 33 70 0a 06 53 54 53 37 a4 6b a0 0f 92  EID3p..STS7.k...
  1300: 93 69 0a 01 70 0a 0a 53 54 53 37 a4 6b 7d 7b 50  .i..p..STS7.k}{P
  1310: 44 43 37 0c ff ff ff 7f 00 43 41 50 37 50 44 43  DC7......CAP7PDC
  1320: 37 a0 45 08 7b 43 46 47 44 0a 01 00 a0 4a 07 90  7.E.{CFGD....J..
  1330: 90 7d 7d 7b 43 46 47 44 0c 00 00 00 08 00 7b 43  .}}{CFGD......{C
  1340: 46 47 44 0c 00 00 00 04 00 00 7d 7b 43 46 47 44  FGD.......}{CFGD
  1350: 0c 00 00 00 01 00 7b 43 46 47 44 0c 00 00 00 02  ......{CFGD.....
  1360: 00 00 00 93 7b 50 44 43 37 0a 09 00 0a 09 92 7b  ....{PDC7......{
  1370: 53 44 54 4c 0b 00 40 00 7d 53 44 54 4c 0b 00 40  SDTL..@.}SDTL..@
  1380: 53 44 54 4c 5b 80 49 53 54 37 00 83 88 53 53 44  SDTL[.IST7...SSD
  1390: 54 0a 28 00 83 88 53 53 44 54 0a 29 00 5b 20 49  T.(...SSDT.).[ I
  13a0: 53 54 37 48 49 37 5f a0 4b 05 7b 43 46 47 44 0a  ST7HI7_.K.{CFGD.
  13b0: f0 00 a0 40 05 90 90 7b 43 46 47 44 0c 00 00 00  ...@...{CFGD....
  13c0: 01 00 7b 50 44 43 37 0a 18 00 92 7b 53 44 54 4c  ..{PDC7....{SDTL
  13d0: 0b 00 80 00 7d 53 44 54 4c 0b 00 80 53 44 54 4c  ....}SDTL...SDTL
  13e0: 5b 80 43 53 54 37 00 83 88 53 53 44 54 0a 2e 00  [.CST7...SSDT...
  13f0: 83 88 53 53 44 54 0a 2f 00 5b 20 43 53 54 37 48  ..SSDT./.[ CST7H
  1400: 43 37 5f a4 6b                                   C7_.k

XSDT @ 0xbff5880c
  0000: 58 53 44 54 d4 00 00 00 01 87 50 54 4c 54 44 20  XSDT......PTLTD
  0010: 09 20 58 53 44 54 20 20 00 00 04 06 20 4c 54 50  . XSDT  .... LTP
  0020: 00 00 00 00 ec 02 f6 bf 00 00 00 00 e0 03 f6 bf  ................
  0030: 00 00 00 00 c0 04 f6 bf 00 00 00 00 f2 04 f6 bf  ................
  0040: 00 00 00 00 c6 05 f6 bf 00 00 00 00 02 06 f6 bf  ................
  0050: 00 00 00 00 3a 06 f6 bf 00 00 00 00 62 06 f6 bf  ....:.......b...
  0060: 00 00 00 00 b2 06 f6 bf 00 00 00 00 42 0c f6 bf  ............B...
  0070: 00 00 00 00 ea 0c f6 bf 00 00 00 00 1a 0d f6 bf  ................
  0080: 00 00 00 00 8a 0e f6 bf 00 00 00 00 6f a1 f5 bf  ............o...
  0090: 00 00 00 00 c9 a0 f5 bf 00 00 00 00 23 a0 f5 bf  ............#...
  00a0: 00 00 00 00 7d 9f f5 bf 00 00 00 00 d7 9e f5 bf  ....}...........
  00b0: 00 00 00 00 31 9e f5 bf 00 00 00 00 8b 9d f5 bf  ....1...........
  00c0: 00 00 00 00 e5 9c f5 bf 00 00 00 00 e0 88 f5 bf  ................
  00d0: 00 00 00 00                                      ....

FACP @ 0xbff60278
  0000: 46 41 43 50 74 00 00 00 01 70 49 4e 54 45 4c 20  FACPt....pINTEL
  0010: 53 54 4f 41 4b 4c 45 59 00 00 04 06 50 54 4c 20  STOAKLEY....PTL
  0020: 03 00 00 00 c0 1f f6 bf 68 b8 f5 bf 00 00 09 00  ........h.......
  0030: b2 00 00 00 f0 f1 00 80 00 10 00 00 00 00 00 00  ................
  0040: 04 10 00 00 00 00 00 00 20 10 00 00 08 10 00 00  ........ .......
  0050: 28 10 00 00 00 00 00 00 04 02 01 04 08 00 00 85  (...............
  0060: 01 00 23 00 00 00 00 00 01 03 0d 00 32 00 00 00  ..#.........2...
  0070: a5 10 00 00                                      ....

Wrong checksum for !
RSDT @ 0xbff58790
  0000: 52 53 44 54 7c 00 00 00 01 48 50 54 4c 54 44 20  RSDT|....HPTLTD
  0010: 20 20 52 53 44 54 20 20 00 00 04 06 20 4c 54 50    RSDT  .... LTP
  0020: 00 00 00 00 78 02 f6 bf e0 03 f6 bf c0 04 f6 bf  ....x...........
  0030: f2 04 f6 bf c6 05 f6 bf 02 06 f6 bf 3a 06 f6 bf  ............:...
  0040: 62 06 f6 bf b2 06 f6 bf 42 0c f6 bf ea 0c f6 bf  b.......B.......
  0050: 1a 0d f6 bf 8a 0e f6 bf 6f a1 f5 bf c9 a0 f5 bf  ........o.......
  0060: 23 a0 f5 bf 7d 9f f5 bf d7 9e f5 bf 31 9e f5 bf  #...}.......1...
  0070: 8b 9d f5 bf e5 9c f5 bf e0 88 f5 bf              ............

RSD PTR @ 0xf6800
  0000: 52 53 44 20 50 54 52 20 6c 50 54 4c 54 44 20 02  RSD PTR lPTLTD .
  0010: 90 87 f5 bf 24 00 00 00 0c 88 f5 bf 00 00 00 00  ....$...........
  0020: 94 00 00 00                                      ....

They also suggested trying various mtrr options in the bios (discrete
mtrr allocation) but they didn't seem to make any difference.

Andy

Re: [PATCH] VT-d: improve RMRR validity checking

[Weidong Han]

Andrew Lyon wrote:
> On Thu, Jan 21, 2010 at 8:25 AM, Noboru Iwamatsu
> <n_iwamatsu@jp.fujitsu.com> wrote:
>   
>> Hi,
>>
>> Some Q35 mainboard that has buggy BIOS, I have one of this,
>> reports invalid DRHD in addition to the invalid RMRR.
>>
>> Attached patch fixes this DRHD issue in the same way as RMRR.
>> And also, I fixed RMRR validity checking loop.
>>
>> Noboru.
>>
>> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
>>
>>
>> -------- Original Message  --------
>> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
>> From: Han, Weidong <weidong.han@intel.com>
>> To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com>
>> Date: Thu Jan 21 2010 11:46:12 GMT+0900
>>
>>     
>>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is set
>>> incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the
>>> device under its scope are not pci discoverable, because the RMRR won't be
>>> used by non-existed or disabled devices.
>>>
>>> This patch ignores the RMRR if the device under its scope are not pci
>>> discoverable, and only checks the validity of RMRRs that are actually used.
>>> In order to avoid duplicate pci device detection code, this patch defines a
>>> function pci_device_detect for it.
>>>
>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>       
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>>     
>
> I have a Supermicro X7DWA-N system which requires
> iommu_inclusive_mapping=1 in order to boot Xen successfully with iommu
> enabled, I am going to try these patches to see if the workaround is
> still necessary but I would also like to ask for some help in getting
> the bios fixed properly , I contacted Supermicro about this issue last
> year and they said they would fix it but they wanted details of
> exactly what was wrong, I tried to figure it out by using acpidump and
> reading the rmrr spec but I failed to make sense of it, perhaps you
> could have a quick look at this dump and let me know if there is
> anything obviously wrong?
>  
>   

iommu_inclusive_mapping=1 workarounds another problem. These code in Xen just makes Xen more defensive to BIOS errors. The final solution is to get them fixed in BIOS.

Regards,
Weidong

Re: [PATCH] VT-d: improve RMRR validity checking

[Keir Fraser]

Given Weidong's comments I will drop these patches and wait for a re-send,
plus Acks from Weidong.

 -- Keir

On 21/01/2010 08:25, "Noboru Iwamatsu" <n_iwamatsu@jp.fujitsu.com> wrote:

> Hi,
> 
> Some Q35 mainboard that has buggy BIOS, I have one of this,
> reports invalid DRHD in addition to the invalid RMRR.
> 
> Attached patch fixes this DRHD issue in the same way as RMRR.
> And also, I fixed RMRR validity checking loop.
> 
> Noboru.
> 
> Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
> 
> 
> -------- Original Message  --------
> Subject: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
> From: Han, Weidong <weidong.han@intel.com>
> To: xen-devel@lists.xensource.com <xen-devel@lists.xensource.com>
> Date: Thu Jan 21 2010 11:46:12 GMT+0900
> 
>> Currently, Xen checks RMRR range and disables VT-d if RMRR range is set
>> incorrectly in BIOS rigorously. But, actually we can ignore the RMRR if the
>> device under its scope are not pci discoverable, because the RMRR won't be
>> used by non-existed or disabled devices.
>> 
>> This patch ignores the RMRR if the device under its scope are not pci
>> discoverable, and only checks the validity of RMRRs that are actually used.
>> In order to avoid duplicate pci device detection code, this patch defines a
>> function pci_device_detect for it.
>> 
>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>