* [PATCH] VT-d: improve RMRR validity checking
@ 2010-01-21 2:46 Han, Weidong
2010-01-21 8:25 ` Noboru Iwamatsu
0 siblings, 1 reply; 76+ messages in thread
From: Han, Weidong @ 2010-01-21 2:46 UTC (permalink / raw)
To: xen-devel; +Cc: Keir Fraser
[-- 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 2:46 [PATCH] VT-d: improve RMRR validity checking Han, Weidong
@ 2010-01-21 8:25 ` Noboru Iwamatsu
2010-01-21 8:38 ` Han, Weidong
` (2 more replies)
0 siblings, 3 replies; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-21 8:25 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel, keir.fraser
[-- 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* RE: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 8:25 ` Noboru Iwamatsu
@ 2010-01-21 8:38 ` Han, Weidong
2010-01-21 10:03 ` Noboru Iwamatsu
2010-01-21 8:45 ` Andrew Lyon
2010-01-21 9:15 ` Keir Fraser
2 siblings, 1 reply; 76+ messages in thread
From: Han, Weidong @ 2010-01-21 8:38 UTC (permalink / raw)
To: Noboru Iwamatsu; +Cc: xen-devel, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 8:25 ` Noboru Iwamatsu
2010-01-21 8:38 ` Han, Weidong
@ 2010-01-21 8:45 ` Andrew Lyon
2010-01-21 10:03 ` Weidong Han
2010-01-21 9:15 ` Keir Fraser
2 siblings, 1 reply; 76+ messages in thread
From: Andrew Lyon @ 2010-01-21 8:45 UTC (permalink / raw)
To: Noboru Iwamatsu; +Cc: xen-devel, weidong.han
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 8:25 ` Noboru Iwamatsu
2010-01-21 8:38 ` Han, Weidong
2010-01-21 8:45 ` Andrew Lyon
@ 2010-01-21 9:15 ` Keir Fraser
2 siblings, 0 replies; 76+ messages in thread
From: Keir Fraser @ 2010-01-21 9:15 UTC (permalink / raw)
To: Noboru Iwamatsu, weidong.han; +Cc: xen-devel
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
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 8:45 ` Andrew Lyon
@ 2010-01-21 10:03 ` Weidong Han
0 siblings, 0 replies; 76+ messages in thread
From: Weidong Han @ 2010-01-21 10:03 UTC (permalink / raw)
To: Andrew Lyon; +Cc: xen-devel, Noboru Iwamatsu
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 8:38 ` Han, Weidong
@ 2010-01-21 10:03 ` Noboru Iwamatsu
2010-01-21 10:08 ` Noboru Iwamatsu
2010-01-21 10:13 ` Weidong Han
0 siblings, 2 replies; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-21 10:03 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel
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
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 10:03 ` Noboru Iwamatsu
@ 2010-01-21 10:08 ` Noboru Iwamatsu
2010-01-21 10:19 ` Weidong Han
2010-01-21 10:13 ` Weidong Han
1 sibling, 1 reply; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-21 10:08 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel
> 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 10:03 ` Noboru Iwamatsu
2010-01-21 10:08 ` Noboru Iwamatsu
@ 2010-01-21 10:13 ` Weidong Han
2010-01-21 12:09 ` Noboru Iwamatsu
1 sibling, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-21 10:13 UTC (permalink / raw)
To: Noboru Iwamatsu; +Cc: xen-devel
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
>>>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 10:08 ` Noboru Iwamatsu
@ 2010-01-21 10:19 ` Weidong Han
2010-01-21 10:27 ` Keir Fraser
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-21 10:19 UTC (permalink / raw)
To: Noboru Iwamatsu; +Cc: xen-devel
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
>>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 10:19 ` Weidong Han
@ 2010-01-21 10:27 ` Keir Fraser
2010-01-21 10:49 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Keir Fraser @ 2010-01-21 10:27 UTC (permalink / raw)
To: Weidong Han, Noboru Iwamatsu; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 10:27 ` Keir Fraser
@ 2010-01-21 10:49 ` Weidong Han
2010-01-21 12:19 ` Noboru Iwamatsu
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-21 10:49 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Noboru Iwamatsu
[-- 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 10:13 ` Weidong Han
@ 2010-01-21 12:09 ` Noboru Iwamatsu
2010-01-21 12:38 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-21 12:09 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel
[-- 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 10:49 ` Weidong Han
@ 2010-01-21 12:19 ` Noboru Iwamatsu
2010-01-21 12:46 ` Weidong Han
2010-01-21 15:04 ` Keir Fraser
0 siblings, 2 replies; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-21 12:19 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel, keir.fraser
[-- 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 12:09 ` Noboru Iwamatsu
@ 2010-01-21 12:38 ` Weidong Han
2010-01-22 0:23 ` Noboru Iwamatsu
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-21 12:38 UTC (permalink / raw)
To: Noboru Iwamatsu; +Cc: xen-devel
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
>>>>>
>>>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 12:19 ` Noboru Iwamatsu
@ 2010-01-21 12:46 ` Weidong Han
2010-01-21 14:01 ` Keir Fraser
2010-01-21 14:17 ` Sander Eikelenboom
2010-01-21 15:04 ` Keir Fraser
1 sibling, 2 replies; 76+ messages in thread
From: Weidong Han @ 2010-01-21 12:46 UTC (permalink / raw)
To: Noboru Iwamatsu; +Cc: Cihula, Joseph, xen-devel, keir.fraser
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>
>>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 12:46 ` Weidong Han
@ 2010-01-21 14:01 ` Keir Fraser
2010-01-21 14:17 ` Sander Eikelenboom
1 sibling, 0 replies; 76+ messages in thread
From: Keir Fraser @ 2010-01-21 14:01 UTC (permalink / raw)
To: Weidong Han, Noboru Iwamatsu; +Cc: Cihula, Joseph, xen-devel
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 12:46 ` Weidong Han
2010-01-21 14:01 ` Keir Fraser
@ 2010-01-21 14:17 ` Sander Eikelenboom
2010-01-21 14:33 ` Keir Fraser
2010-01-21 15:28 ` Andrew Lyon
1 sibling, 2 replies; 76+ messages in thread
From: Sander Eikelenboom @ 2010-01-21 14:17 UTC (permalink / raw)
To: Weidong Han; +Cc: Cihula, Joseph, Noboru Iwamatsu, xen-devel, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 14:17 ` Sander Eikelenboom
@ 2010-01-21 14:33 ` Keir Fraser
2010-01-22 2:12 ` Weidong Han
2010-01-21 15:28 ` Andrew Lyon
1 sibling, 1 reply; 76+ messages in thread
From: Keir Fraser @ 2010-01-21 14:33 UTC (permalink / raw)
To: Sander Eikelenboom, Weidong Han
Cc: Cihula, Joseph, Noboru Iwamatsu, xen-devel
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>
>>>>
>>>
>>>
>
>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 12:19 ` Noboru Iwamatsu
2010-01-21 12:46 ` Weidong Han
@ 2010-01-21 15:04 ` Keir Fraser
2010-01-22 1:35 ` Noboru Iwamatsu
1 sibling, 1 reply; 76+ messages in thread
From: Keir Fraser @ 2010-01-21 15:04 UTC (permalink / raw)
To: Noboru Iwamatsu, weidong.han; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 14:17 ` Sander Eikelenboom
2010-01-21 14:33 ` Keir Fraser
@ 2010-01-21 15:28 ` Andrew Lyon
1 sibling, 0 replies; 76+ messages in thread
From: Andrew Lyon @ 2010-01-21 15:28 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: Noboru Iwamatsu, Cihula, Joseph, Weidong Han, xen-devel, keir.fraser
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
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 12:38 ` Weidong Han
@ 2010-01-22 0:23 ` Noboru Iwamatsu
0 siblings, 0 replies; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-22 0:23 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel
> 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
>>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 15:04 ` Keir Fraser
@ 2010-01-22 1:35 ` Noboru Iwamatsu
0 siblings, 0 replies; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-22 1:35 UTC (permalink / raw)
To: keir.fraser; +Cc: xen-devel, weidong.han
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-21 14:33 ` Keir Fraser
@ 2010-01-22 2:12 ` Weidong Han
2010-01-22 2:38 ` Noboru Iwamatsu
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-22 2:12 UTC (permalink / raw)
To: Keir Fraser
Cc: Sander Eikelenboom, Cihula, Joseph, Noboru Iwamatsu, xen-devel
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>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 2:12 ` Weidong Han
@ 2010-01-22 2:38 ` Noboru Iwamatsu
2010-01-22 2:53 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-22 2:38 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel, linux, joseph.cihula, keir.fraser
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>
>>>
>>>
>>>
>>
>>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 2:38 ` Noboru Iwamatsu
@ 2010-01-22 2:53 ` Weidong Han
2010-01-22 3:16 ` Noboru Iwamatsu
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-22 2:53 UTC (permalink / raw)
To: Noboru Iwamatsu; +Cc: xen-devel, linux, Cihula, Joseph, keir.fraser
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>
>>>>>>>
>>>>
>>>>
>>>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 2:53 ` Weidong Han
@ 2010-01-22 3:16 ` Noboru Iwamatsu
2010-01-22 8:47 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-22 3:16 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel, linux, joseph.cihula, keir.fraser
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>
>>>>>
>>
>>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 3:16 ` Noboru Iwamatsu
@ 2010-01-22 8:47 ` Weidong Han
2010-01-22 9:19 ` Sander Eikelenboom
` (2 more replies)
0 siblings, 3 replies; 76+ messages in thread
From: Weidong Han @ 2010-01-22 8:47 UTC (permalink / raw)
To: Noboru Iwamatsu
Cc: xen-devel, linux, Cihula, Joseph, Kay, Allen M, keir.fraser
[-- 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 8:47 ` Weidong Han
@ 2010-01-22 9:19 ` Sander Eikelenboom
2010-01-22 12:15 ` Weidong Han
2010-01-25 7:06 ` [PATCH] VT-d: improve RMRR validity checking Noboru Iwamatsu
2010-03-09 21:39 ` Alex Williamson
2 siblings, 1 reply; 76+ messages in thread
From: Sander Eikelenboom @ 2010-01-22 9:19 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Kay, Allen M, Cihula, Joseph, Noboru Iwamatsu, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 9:19 ` Sander Eikelenboom
@ 2010-01-22 12:15 ` Weidong Han
2010-01-22 12:32 ` Pasi Kärkkäinen
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-22 12:15 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: xen-devel, Kay, Allen M, Cihula, Joseph, Noboru Iwamatsu, keir.fraser
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;
>> }
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 12:15 ` Weidong Han
@ 2010-01-22 12:32 ` Pasi Kärkkäinen
2010-01-23 12:40 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Pasi Kärkkäinen @ 2010-01-22 12:32 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M,
Sander Eikelenboom, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 12:32 ` Pasi Kärkkäinen
@ 2010-01-23 12:40 ` Weidong Han
2010-01-23 13:08 ` Pasi Kärkkäinen
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-23 12:40 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M,
Sander Eikelenboom, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-23 12:40 ` Weidong Han
@ 2010-01-23 13:08 ` Pasi Kärkkäinen
2010-01-23 14:33 ` Sander Eikelenboom
0 siblings, 1 reply; 76+ messages in thread
From: Pasi Kärkkäinen @ 2010-01-23 13:08 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M,
Sander Eikelenboom, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-23 13:08 ` Pasi Kärkkäinen
@ 2010-01-23 14:33 ` Sander Eikelenboom
2010-01-23 14:54 ` [PATCH] VT-d: improve RMRR validity checking, documenting boot options Pasi Kärkkäinen
0 siblings, 1 reply; 76+ messages in thread
From: Sander Eikelenboom @ 2010-01-23 14:33 UTC (permalink / raw)
To: Pasi Kärkkäinen
Cc: xen-devel, Noboru Iwamatsu, Weidong Han, Cihula, Joseph, Kay,
Allen M, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options
2010-01-23 14:33 ` Sander Eikelenboom
@ 2010-01-23 14:54 ` Pasi Kärkkäinen
2010-01-25 16:40 ` Stephen Spector
0 siblings, 1 reply; 76+ messages in thread
From: Pasi Kärkkäinen @ 2010-01-23 14:54 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: xen-devel, Noboru Iwamatsu, Weidong Han, Cihula, Joseph, Kay,
Allen M, keir.fraser, Stephen Spector
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
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 8:47 ` Weidong Han
2010-01-22 9:19 ` Sander Eikelenboom
@ 2010-01-25 7:06 ` Noboru Iwamatsu
2010-01-25 7:56 ` Weidong Han
2010-03-09 21:39 ` Alex Williamson
2 siblings, 1 reply; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-25 7:06 UTC (permalink / raw)
To: weidong.han, keir.fraser; +Cc: linux, joseph.cihula, allen.m.kay, xen-devel
[-- 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 7:06 ` [PATCH] VT-d: improve RMRR validity checking Noboru Iwamatsu
@ 2010-01-25 7:56 ` Weidong Han
2010-01-25 9:02 ` Sander Eikelenboom
2010-01-25 9:22 ` Noboru Iwamatsu
0 siblings, 2 replies; 76+ messages in thread
From: Weidong Han @ 2010-01-25 7:56 UTC (permalink / raw)
To: Noboru Iwamatsu
Cc: xen-devel, linux, Cihula, Joseph, Kay, Allen M, keir.fraser
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>
>>>>>>>>>>>
>>>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 7:56 ` Weidong Han
@ 2010-01-25 9:02 ` Sander Eikelenboom
2010-01-25 9:11 ` Weidong Han
2010-01-25 9:22 ` Noboru Iwamatsu
1 sibling, 1 reply; 76+ messages in thread
From: Sander Eikelenboom @ 2010-01-25 9:02 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Kay, Allen M, Cihula, Joseph, Noboru Iwamatsu, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 9:02 ` Sander Eikelenboom
@ 2010-01-25 9:11 ` Weidong Han
0 siblings, 0 replies; 76+ messages in thread
From: Weidong Han @ 2010-01-25 9:11 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: xen-devel, Kay, Allen M, Cihula, Joseph, Noboru Iwamatsu, keir.fraser
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>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 7:56 ` Weidong Han
2010-01-25 9:02 ` Sander Eikelenboom
@ 2010-01-25 9:22 ` Noboru Iwamatsu
2010-01-25 10:08 ` Weidong Han
1 sibling, 1 reply; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-25 9:22 UTC (permalink / raw)
To: weidong.han; +Cc: xen-devel, linux, joseph.cihula, allen.m.kay, keir.fraser
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>
>>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 9:22 ` Noboru Iwamatsu
@ 2010-01-25 10:08 ` Weidong Han
2010-01-25 10:45 ` Sander Eikelenboom
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-25 10:08 UTC (permalink / raw)
To: Noboru Iwamatsu
Cc: xen-devel, linux, Cihula, Joseph, Kay, Allen M, keir.fraser
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>
>>>>>>>>>>>>>
>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 10:08 ` Weidong Han
@ 2010-01-25 10:45 ` Sander Eikelenboom
2010-01-25 13:43 ` Keir Fraser
0 siblings, 1 reply; 76+ messages in thread
From: Sander Eikelenboom @ 2010-01-25 10:45 UTC (permalink / raw)
To: Weidong Han
Cc: Cihula, Joseph, Kay, Allen M, xen-devel, Noboru Iwamatsu, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 10:45 ` Sander Eikelenboom
@ 2010-01-25 13:43 ` Keir Fraser
2010-01-25 13:57 ` Christian Tramnitz
` (3 more replies)
0 siblings, 4 replies; 76+ messages in thread
From: Keir Fraser @ 2010-01-25 13:43 UTC (permalink / raw)
To: Sander Eikelenboom, Weidong Han
Cc: Cihula, Joseph, Kay, Allen M, xen-devel, Noboru Iwamatsu
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 13:43 ` Keir Fraser
@ 2010-01-25 13:57 ` Christian Tramnitz
2010-01-25 14:10 ` Weidong Han
` (2 subsequent siblings)
3 siblings, 0 replies; 76+ messages in thread
From: Christian Tramnitz @ 2010-01-25 13:57 UTC (permalink / raw)
To: xen-devel
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 13:43 ` Keir Fraser
2010-01-25 13:57 ` Christian Tramnitz
@ 2010-01-25 14:10 ` Weidong Han
2010-01-26 1:16 ` Noboru Iwamatsu
2010-01-25 14:12 ` Weidong Han
2010-01-25 14:13 ` Han, Weidong
3 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-25 14:10 UTC (permalink / raw)
To: Keir Fraser
Cc: Sander Eikelenboom, Cihula, Joseph, xen-devel, Noboru Iwamatsu,
Kay, Allen M
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 13:43 ` Keir Fraser
2010-01-25 13:57 ` Christian Tramnitz
2010-01-25 14:10 ` Weidong Han
@ 2010-01-25 14:12 ` Weidong Han
2010-01-25 14:13 ` Han, Weidong
3 siblings, 0 replies; 76+ messages in thread
From: Weidong Han @ 2010-01-25 14:12 UTC (permalink / raw)
To: Keir Fraser
Cc: Sander Eikelenboom, Cihula, Joseph, xen-devel, Noboru Iwamatsu,
Kay, Allen M
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* RE: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 13:43 ` Keir Fraser
` (2 preceding siblings ...)
2010-01-25 14:12 ` Weidong Han
@ 2010-01-25 14:13 ` Han, Weidong
3 siblings, 0 replies; 76+ messages in thread
From: Han, Weidong @ 2010-01-25 14:13 UTC (permalink / raw)
To: Keir Fraser, Sander Eikelenboom
Cc: Cihula, Joseph, Kay, Allen M, xen-devel, Noboru Iwamatsu
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* RE: [PATCH] VT-d: improve RMRR validity checking, documenting boot options
2010-01-23 14:54 ` [PATCH] VT-d: improve RMRR validity checking, documenting boot options Pasi Kärkkäinen
@ 2010-01-25 16:40 ` Stephen Spector
2010-01-25 16:58 ` Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options) Sander Eikelenboom
0 siblings, 1 reply; 76+ messages in thread
From: Stephen Spector @ 2010-01-25 16:40 UTC (permalink / raw)
To: 'Pasi Kärkkäinen', Sander Eikelenboom
Cc: xen-devel, Noboru Iwamatsu, Weidong Han, Cihula, Joseph, Kay,
Allen M, Keir Fraser
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
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options)
2010-01-25 16:40 ` Stephen Spector
@ 2010-01-25 16:58 ` Sander Eikelenboom
2010-01-25 20:56 ` Stephen Spector
0 siblings, 1 reply; 76+ messages in thread
From: Sander Eikelenboom @ 2010-01-25 16:58 UTC (permalink / raw)
To: Stephen Spector; +Cc: xen-devel, Keir Fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* RE: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options)
2010-01-25 16:58 ` Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options) Sander Eikelenboom
@ 2010-01-25 20:56 ` Stephen Spector
2010-01-27 11:33 ` Pasi Kärkkäinen
0 siblings, 1 reply; 76+ messages in thread
From: Stephen Spector @ 2010-01-25 20:56 UTC (permalink / raw)
To: 'Sander Eikelenboom'; +Cc: xen-devel, Keir Fraser
> 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-25 14:10 ` Weidong Han
@ 2010-01-26 1:16 ` Noboru Iwamatsu
2010-01-26 5:51 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-26 1:16 UTC (permalink / raw)
To: weidong.han, keir.fraser; +Cc: linux, joseph.cihula, xen-devel, allen.m.kay
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
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-26 1:16 ` Noboru Iwamatsu
@ 2010-01-26 5:51 ` Weidong Han
2010-01-26 6:38 ` Noboru Iwamatsu
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-01-26 5:51 UTC (permalink / raw)
To: Noboru Iwamatsu
Cc: linux, Cihula, Joseph, xen-devel, Kay, Allen M, keir.fraser
[-- 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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-26 5:51 ` Weidong Han
@ 2010-01-26 6:38 ` Noboru Iwamatsu
2010-01-26 6:42 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Noboru Iwamatsu @ 2010-01-26 6:38 UTC (permalink / raw)
To: weidong.han; +Cc: linux, joseph.cihula, xen-devel, allen.m.kay, keir.fraser
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
>>>
>>>
>>>
>>
>>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-26 6:38 ` Noboru Iwamatsu
@ 2010-01-26 6:42 ` Weidong Han
0 siblings, 0 replies; 76+ messages in thread
From: Weidong Han @ 2010-01-26 6:42 UTC (permalink / raw)
To: Noboru Iwamatsu
Cc: linux, Cihula, Joseph, xen-devel, Kay, Allen M, keir.fraser
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
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options)
2010-01-25 20:56 ` Stephen Spector
@ 2010-01-27 11:33 ` Pasi Kärkkäinen
0 siblings, 0 replies; 76+ messages in thread
From: Pasi Kärkkäinen @ 2010-01-27 11:33 UTC (permalink / raw)
To: Stephen Spector; +Cc: 'Sander Eikelenboom', xen-devel, Keir Fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-09 21:39 ` Alex Williamson
@ 2010-03-09 21:30 ` Konrad Rzeszutek Wilk
2010-03-09 21:57 ` Alex Williamson
2010-03-10 2:40 ` Weidong Han
1 sibling, 1 reply; 76+ messages in thread
From: Konrad Rzeszutek Wilk @ 2010-03-09 21:30 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Kay, Allen M, Cihula, Joseph,
Weidong Han, linux, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-01-22 8:47 ` Weidong Han
2010-01-22 9:19 ` Sander Eikelenboom
2010-01-25 7:06 ` [PATCH] VT-d: improve RMRR validity checking Noboru Iwamatsu
@ 2010-03-09 21:39 ` Alex Williamson
2010-03-09 21:30 ` Konrad Rzeszutek Wilk
2010-03-10 2:40 ` Weidong Han
2 siblings, 2 replies; 76+ messages in thread
From: Alex Williamson @ 2010-03-09 21:39 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-09 21:30 ` Konrad Rzeszutek Wilk
@ 2010-03-09 21:57 ` Alex Williamson
2010-03-09 22:22 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-09 21:57 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, Noboru Iwamatsu, Weidong Han, Cihula, Joseph, Kay,
Allen M, linux, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-09 21:57 ` Alex Williamson
@ 2010-03-09 22:22 ` Konrad Rzeszutek Wilk
2010-03-09 23:05 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Konrad Rzeszutek Wilk @ 2010-03-09 22:22 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Weidong Han, Cihula, Joseph, Kay,
Allen M, linux, keir.fraser
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.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-09 22:22 ` Konrad Rzeszutek Wilk
@ 2010-03-09 23:05 ` Alex Williamson
2010-03-09 23:25 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-09 23:05 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, Noboru Iwamatsu, Weidong Han, Cihula, Joseph, Kay,
Allen M, linux, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-09 23:05 ` Alex Williamson
@ 2010-03-09 23:25 ` Alex Williamson
2010-03-10 2:13 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-09 23:25 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, Noboru Iwamatsu, Kay, Allen M, Cihula, Joseph,
Weidong Han, linux, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-09 23:25 ` Alex Williamson
@ 2010-03-10 2:13 ` Alex Williamson
0 siblings, 0 replies; 76+ messages in thread
From: Alex Williamson @ 2010-03-10 2:13 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel, Noboru Iwamatsu, Kay, Allen M, Cihula, Joseph,
Weidong Han, linux, keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-09 21:39 ` Alex Williamson
2010-03-09 21:30 ` Konrad Rzeszutek Wilk
@ 2010-03-10 2:40 ` Weidong Han
2010-03-10 3:18 ` Alex Williamson
1 sibling, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-03-10 2:40 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 2:40 ` Weidong Han
@ 2010-03-10 3:18 ` Alex Williamson
2010-03-10 3:28 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-10 3:18 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 3:18 ` Alex Williamson
@ 2010-03-10 3:28 ` Weidong Han
2010-03-10 3:37 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-03-10 3:28 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 3:28 ` Weidong Han
@ 2010-03-10 3:37 ` Alex Williamson
2010-03-10 4:25 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-10 3:37 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 3:37 ` Alex Williamson
@ 2010-03-10 4:25 ` Weidong Han
2010-03-10 4:47 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-03-10 4:25 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 4:25 ` Weidong Han
@ 2010-03-10 4:47 ` Alex Williamson
2010-03-10 7:03 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-10 4:47 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 4:47 ` Alex Williamson
@ 2010-03-10 7:03 ` Weidong Han
2010-03-10 13:56 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-03-10 7:03 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 7:03 ` Weidong Han
@ 2010-03-10 13:56 ` Alex Williamson
2010-03-10 18:06 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-10 13:56 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 13:56 ` Alex Williamson
@ 2010-03-10 18:06 ` Alex Williamson
2010-03-11 2:11 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-10 18:06 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-10 18:06 ` Alex Williamson
@ 2010-03-11 2:11 ` Weidong Han
2010-03-11 2:32 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-03-11 2:11 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-11 2:11 ` Weidong Han
@ 2010-03-11 2:32 ` Alex Williamson
2010-03-11 3:44 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-11 2:32 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-11 2:32 ` Alex Williamson
@ 2010-03-11 3:44 ` Weidong Han
2010-03-11 4:52 ` Alex Williamson
0 siblings, 1 reply; 76+ messages in thread
From: Weidong Han @ 2010-03-11 3:44 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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
>>
>>
>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-11 3:44 ` Weidong Han
@ 2010-03-11 4:52 ` Alex Williamson
2010-03-11 8:30 ` Weidong Han
0 siblings, 1 reply; 76+ messages in thread
From: Alex Williamson @ 2010-03-11 4:52 UTC (permalink / raw)
To: Weidong Han
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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]);
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH] VT-d: improve RMRR validity checking
2010-03-11 4:52 ` Alex Williamson
@ 2010-03-11 8:30 ` Weidong Han
0 siblings, 0 replies; 76+ messages in thread
From: Weidong Han @ 2010-03-11 8:30 UTC (permalink / raw)
To: Alex Williamson
Cc: xen-devel, Noboru Iwamatsu, Cihula, Joseph, Kay, Allen M, linux,
keir.fraser
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]);
>>
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 76+ messages in thread
end of thread, other threads:[~2010-03-11 8:30 UTC | newest]
Thread overview: 76+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-21 2:46 [PATCH] VT-d: improve RMRR validity checking Han, Weidong
2010-01-21 8:25 ` Noboru Iwamatsu
2010-01-21 8:38 ` Han, Weidong
2010-01-21 10:03 ` Noboru Iwamatsu
2010-01-21 10:08 ` Noboru Iwamatsu
2010-01-21 10:19 ` Weidong Han
2010-01-21 10:27 ` Keir Fraser
2010-01-21 10:49 ` Weidong Han
2010-01-21 12:19 ` Noboru Iwamatsu
2010-01-21 12:46 ` Weidong Han
2010-01-21 14:01 ` Keir Fraser
2010-01-21 14:17 ` Sander Eikelenboom
2010-01-21 14:33 ` Keir Fraser
2010-01-22 2:12 ` Weidong Han
2010-01-22 2:38 ` Noboru Iwamatsu
2010-01-22 2:53 ` Weidong Han
2010-01-22 3:16 ` Noboru Iwamatsu
2010-01-22 8:47 ` Weidong Han
2010-01-22 9:19 ` Sander Eikelenboom
2010-01-22 12:15 ` Weidong Han
2010-01-22 12:32 ` Pasi Kärkkäinen
2010-01-23 12:40 ` Weidong Han
2010-01-23 13:08 ` Pasi Kärkkäinen
2010-01-23 14:33 ` Sander Eikelenboom
2010-01-23 14:54 ` [PATCH] VT-d: improve RMRR validity checking, documenting boot options Pasi Kärkkäinen
2010-01-25 16:40 ` Stephen Spector
2010-01-25 16:58 ` Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [PATCH] VT-d: improve RMRR validity checking, documenting boot options) Sander Eikelenboom
2010-01-25 20:56 ` Stephen Spector
2010-01-27 11:33 ` Pasi Kärkkäinen
2010-01-25 7:06 ` [PATCH] VT-d: improve RMRR validity checking Noboru Iwamatsu
2010-01-25 7:56 ` Weidong Han
2010-01-25 9:02 ` Sander Eikelenboom
2010-01-25 9:11 ` Weidong Han
2010-01-25 9:22 ` Noboru Iwamatsu
2010-01-25 10:08 ` Weidong Han
2010-01-25 10:45 ` Sander Eikelenboom
2010-01-25 13:43 ` Keir Fraser
2010-01-25 13:57 ` Christian Tramnitz
2010-01-25 14:10 ` Weidong Han
2010-01-26 1:16 ` Noboru Iwamatsu
2010-01-26 5:51 ` Weidong Han
2010-01-26 6:38 ` Noboru Iwamatsu
2010-01-26 6:42 ` Weidong Han
2010-01-25 14:12 ` Weidong Han
2010-01-25 14:13 ` Han, Weidong
2010-03-09 21:39 ` Alex Williamson
2010-03-09 21:30 ` Konrad Rzeszutek Wilk
2010-03-09 21:57 ` Alex Williamson
2010-03-09 22:22 ` Konrad Rzeszutek Wilk
2010-03-09 23:05 ` Alex Williamson
2010-03-09 23:25 ` Alex Williamson
2010-03-10 2:13 ` Alex Williamson
2010-03-10 2:40 ` Weidong Han
2010-03-10 3:18 ` Alex Williamson
2010-03-10 3:28 ` Weidong Han
2010-03-10 3:37 ` Alex Williamson
2010-03-10 4:25 ` Weidong Han
2010-03-10 4:47 ` Alex Williamson
2010-03-10 7:03 ` Weidong Han
2010-03-10 13:56 ` Alex Williamson
2010-03-10 18:06 ` Alex Williamson
2010-03-11 2:11 ` Weidong Han
2010-03-11 2:32 ` Alex Williamson
2010-03-11 3:44 ` Weidong Han
2010-03-11 4:52 ` Alex Williamson
2010-03-11 8:30 ` Weidong Han
2010-01-21 15:28 ` Andrew Lyon
2010-01-21 15:04 ` Keir Fraser
2010-01-22 1:35 ` Noboru Iwamatsu
2010-01-21 10:13 ` Weidong Han
2010-01-21 12:09 ` Noboru Iwamatsu
2010-01-21 12:38 ` Weidong Han
2010-01-22 0:23 ` Noboru Iwamatsu
2010-01-21 8:45 ` Andrew Lyon
2010-01-21 10:03 ` Weidong Han
2010-01-21 9:15 ` Keir Fraser
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.