Han, Weidong
2010-Jan-21 02:46 UTC
[Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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
Noboru Iwamatsu
2010-Jan-21 08:25 UTC
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
Han, Weidong
2010-Jan-21 08:38 UTC
RE: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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
Andrew Lyon
2010-Jan-21 08:45 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jan-21 09:15 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-21 10:03 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-21 10:03 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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
Noboru Iwamatsu
2010-Jan-21 10:08 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-21 10:13 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >>> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-21 10:19 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jan-21 10:27 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-21 10:49 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-21 12:09 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-21 12:19 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-21 12:38 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >>>>> >>> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-21 12:46 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jan-21 14:01 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2010-Jan-21 14:17 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jan-21 14:33 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >>>> >>> >>> > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jan-21 15:04 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Andrew Lyon
2010-Jan-21 15:28 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-22 00:23 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
> 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 >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-22 01:35 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-22 02:12 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >>>>> >>>>> >>>> >>>> >> >> >> >> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-22 02:38 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >>> >>> >>> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-22 02:53 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >>>>>>> >>>> >>>> >>> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-22 03:16 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >>>>> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-22 08:47 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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>
>>>>>>>>>
>>>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Sander Eikelenboom
2010-Jan-22 09:19 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-22 12:15 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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; >> } >> >> > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jan-22 12:32 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-23 12:40 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jan-23 13:08 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2010-Jan-23 14:33 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jan-23 14:54 UTC
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-25 07:06 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-25 07:56 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >>>>>>>>>>> >>> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2010-Jan-25 09:02 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-25 09:11 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>> >>>>> >>> >>> > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-25 09:22 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-25 10:08 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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> >>>>>>>>>>>>> > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2010-Jan-25 10:45 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2010-Jan-25 13:43 UTC
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christian Tramnitz
2010-Jan-25 13:57 UTC
[Xen-devel] Re: [PATCH] VT-d: improve RMRR validity checking
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-25 14:10 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-25 14:12 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Han, Weidong
2010-Jan-25 14:13 UTC
RE: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stephen Spector
2010-Jan-25 16:40 UTC
RE: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sander Eikelenboom
2010-Jan-25 16:58 UTC
Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options)
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Stephen Spector
2010-Jan-25 20:56 UTC
RE: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options)
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-26 01:16 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-26 05:51 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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
>>
>>
>>
>>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Noboru Iwamatsu
2010-Jan-26 06:38 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >>> >>> >>> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Jan-26 06:42 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >>>> >>>> >>>> >>>> >>> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2010-Jan-27 11:33 UTC
Re: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options)
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Mar-09 21:30 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 aHow 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-09 21:39 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-09 21:57 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Mar-09 22:22 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-09 23:05 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-09 23:25 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-10 02:13 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Mar-10 02:40 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-10 03:18 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Mar-10 03:28 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-10 03:37 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Mar-10 04:25 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-10 04:47 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Mar-10 07:03 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-10 13:56 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-10 18:06 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Mar-11 02:11 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-11 02:32 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Mar-11 03:44 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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 >> >> > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Alex Williamson
2010-Mar-11 04:52 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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]); > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Mar-11 08:30 UTC
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
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]); >> >> >> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel