From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (NAM02-SN1-obe.outbound.protection.outlook.com [40.92.5.80]) by mx.groups.io with SMTP id smtpd.web12.33236.1599204733270168161 for ; Fri, 04 Sep 2020 00:32:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@hotmail.com header.s=selector1 header.b=FuK6qa1+; spf=pass (domain: hotmail.com, ip: 40.92.5.80, mailfrom: vanjeff_919@hotmail.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kttqdO3NgKTjLbxVLEaWJrm4LBkEN0O6NepNnzBfwdEisJscv/RySQnRaJWQWml1gZOWlyL907OkuYc7dbuwzkXEJevfTncj8JHUAUdoBB/KpLXzOIue0ti8WaKNGuGc5P4GP0/7648Qy+9e6VqzP+SqfZUWT0fKPZylaJzbkk/3rNkKydI0paLloAbroYNlS+SoxESVUXVD6vjoMTiWkHSF8Ykwboehz38jCkBawTWJgSatkR6uADbR7blZxaM97Xa6v44TCvtXB45SIouYnTXq2WhroSXkUZGefy9QQC57Cvtk7AZ4+JhgA5axnDaUO6x9fXe27N0e9bEO1tOwEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FsqLk6t04niH4qvhmSpjFvDoDxwyAnfIJCq7e9Ttdcw=; b=a9t/VjB3qnG05f4LC6bs4F5LGzZwLpV6UwaltKoDWhPtktGpP7QgXMC/98xioFoVfqg3tZxltTcg6vX7TLrLt+pkVPHPH/0ltNJjyDiLl0s5yI1rxmXZpG6yzTCIjnsz/RwJ72pMgc/6veHdOwBl9odfQNuWmJ3N0vmtmk4Mdqy5DmB3mBRigS9Ww2CHcAUjlK5+JgARQ7Jdbso0h/x75rq4Jr4Z17RWWU6qnCkJKqB2u0I2pDoxfkJULJvvSWhzGRyNOToSf55ILQpBcBvPM1w0W0qgI7EiGChcFpCkBjNRVrAyFlmvyBc+4f5GP+JMCRpB82ddRc4erpveBQUVJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FsqLk6t04niH4qvhmSpjFvDoDxwyAnfIJCq7e9Ttdcw=; b=FuK6qa1+lnKjIKd0aOWIdBDUBnLQ8cO4ocuOK0CE0Y+qmWJQjOu/Qqfa6LW9DzoP5mPS10jARUSYbPDkLIYC3iMu1ZuVtB5nvQOg4nvRkmkjsKELLJ/QJly5nLqYxCuEVwezxDpEkdjo7+v7PWqGu7o3f/myz/IKgIrx52nWPt355kJVaJe2Ii9zbJIC8oMP8DZYOCaDO8tanNIgMrV1B9XAepv5rhO6pao07nnG4DvSfbh2gFUO4/rD/8njw1HdbwMbs8Xf/0W/1ewE4HtEGE6BZX6E+sKWd9hju/HSsiOt94wUBZMOPKW8XiwQVDfRjmXqapjG3UXyu+pLyVfpkw== Received: from SN1NAM02FT044.eop-nam02.prod.protection.outlook.com (10.152.72.59) by SN1NAM02HT115.eop-nam02.prod.protection.outlook.com (10.152.73.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.21; Fri, 4 Sep 2020 07:32:10 +0000 Received: from MWHPR19MB0030.namprd19.prod.outlook.com (2a01:111:e400:7e44::40) by SN1NAM02FT044.mail.protection.outlook.com (2a01:111:e400:7e44::173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.17 via Frontend Transport; Fri, 4 Sep 2020 07:32:10 +0000 Received: from MWHPR19MB0030.namprd19.prod.outlook.com ([fe80::293e:af2:19ca:8470]) by MWHPR19MB0030.namprd19.prod.outlook.com ([fe80::293e:af2:19ca:8470%4]) with mapi id 15.20.3348.017; Fri, 4 Sep 2020 07:32:09 +0000 From: "Fan Jeff" To: Laszlo Ersek , "devel@edk2.groups.io" , "eric.dong@intel.com" , "Ni, Ray" CC: "Lou, Yun" Subject: =?UTF-8?B?5Zue5aSNOiDlm57lpI06IFtlZGsyLWRldmVsXSBbUEFUQ0ggdjJdIFVlZmlDcHVQa2cvTXBJbml0TGliOiBBZGQgY2hlY2sgZm9yIENSMy9HRFQvSURULg==?= Thread-Topic: =?gb2312?B?u9i4tDogW2VkazItZGV2ZWxdIFtQQVRDSCB2Ml0gVWVmaUNwdVBrZy9NcElu?= =?gb2312?Q?itLib:_Add_check_for_CR3/GDT/IDT.?= Thread-Index: AQHWggSPsVD1Ufr/O0iBw4kxtzfAtalXRPGAgAAPdICAAF6HgIAAB16AgAADd8+AAE+1AIAAAWOr Date: Fri, 4 Sep 2020 07:32:09 +0000 Message-ID: References: <20200903151147.1196-1-eric.dong@intel.com> <9c9d8289-4f8e-75d8-2816-750195a54842@redhat.com> , In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:914570DBB910FB958D8D385F2302CE8BBC5ED2421B06AF09BA2E2287057EA2CF;UpperCasedChecksum:EE0EA420475F26E9F4FE3A4A0C2304980A85868FCC30614733BC04E641C43B11;SizeAsReceived:7559;Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [acK1r5/vd2jx/bo4nBKWVRHqUs9iuwRP] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: e2d59a8f-5cf8-4ca7-ffa9-08d850a4a23e x-ms-traffictypediagnostic: SN1NAM02HT115: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: niPo9yrPudIL6hAvPNgvILbgtxDixsYQo1u0tSTS1D8mwcoDiaBN/2TlUCdln72PpBqo67TH/QafXcxMtCPXfQYV/33NYUT8t4vG9kLgsia/btOv0rp3NQPP5udyPUBvfDfVM7vyt5ZmvxMs+b0VusQjcyMJcghUtyjh3kcShG1w7JfZMVrmPHLme4X++yJOluab7asWJ2AdwQMIa1SiVQ0qAriq1iaolROPD5v8IHxTfdv9KhdMyFTiva2N83Yz x-ms-exchange-antispam-messagedata: TGcyWhcAkSvHG7RAovgvrING6cwoNtiFd8jNrllRjhpnUxC+l2WrOgT2QhWsYojb4qcrBGQYHdSFo46pBSqT9X7TDDMQcqXyAMcAcepXPdUQm+lqv/t5MXk/VKLCn6hurA/fWqqD05dYaaOiYV7gVA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT044.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: e2d59a8f-5cf8-4ca7-ffa9-08d850a4a23e X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2020 07:32:09.8971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT115 Content-Language: zh-CN Content-Type: multipart/alternative; boundary="_000_MWHPR19MB0030EAA3D5A79EA327DDE793D72D0MWHPR19MB0030namp_" --_000_MWHPR19MB0030EAA3D5A79EA327DDE793D72D0MWHPR19MB0030namp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TGFzemxvLA0KDQpXaHkgc3luYyB0aGUgQlNQoa9zIENSMy9HRFQvSURUIHZhbHVlcyBmb3IgQVAg d2hlbiBBUCB3YWtlcyB1cCBpbnN0ZWFkIG9mIHVzaW5nIG9sZCBjYWNoZWQgQlNQoa9zIENSMy9H RFQvSURUIHZhbHVlcyB3aGVuIENQVSBkcml2ZXIgaW5pdGlhbGxseSBkaXNwYXRjaGVkIGlzIHRo YXQgd2UgQ0FOTk9UIGFzc3VtZSBvcmlnaW5hbCB2YWx1ZXMgYXJlIHN0aWxsIHZhbGlkIGR1cmlu ZyBQT1NUIHBoYXNlLg0KDQpPbiB0aGlzIHNlbmFyaW8sIEJTUKGvcyBDUjMvR0RUL0lEVCBhcmUg anVzdCBsaWtlIGlucHV0IHBhcmFtZXRlcnMgZm9yIG9uZSBmdW5jdGlvbi4gVmFsaWRhdGluZyB0 aGVtIGFyZSBuZWNlc3NhcnkuDQoNCkZvciBleGFtcGxlLCBEZWJ1Z0FnZW50RHhlIGRyaXZlciBt YXkgYmUgbG9hZGVkIGluIFVFRkkgc2hlbGwgdG8gc2V0dXAgc291cmNlIGxldmVsIGRlYnVnZ2lu ZyBlbnZpcm9tZW50IG9mIEVES0lJIGRlYnVnZ2VyIHRvb2xzLiAgSXQgbWF5IHNldHVwIG5ldyBJ RFQgc3BhY2UuDQoNCkplZmYNCg0Kt6K8/sjLOiBMYXN6bG8gRXJzZWs8bWFpbHRvOmxlcnNla0By ZWRoYXQuY29tPg0Kt6LLzcqxvOQ6IDIwMjDE6jnUwjTI1SAxNDo1OA0KytW8/sjLOiBGYW4gSmVm ZjxtYWlsdG86dmFuamVmZl85MTlAaG90bWFpbC5jb20+OyBkZXZlbEBlZGsyLmdyb3Vwcy5pbzxt YWlsdG86ZGV2ZWxAZWRrMi5ncm91cHMuaW8+OyBlcmljLmRvbmdAaW50ZWwuY29tPG1haWx0bzpl cmljLmRvbmdAaW50ZWwuY29tPjsgTmksIFJheTxtYWlsdG86cmF5Lm5pQGludGVsLmNvbT4NCrOt y806IExvdSwgWXVuPG1haWx0bzp5dW4ubG91QGludGVsLmNvbT4NCtb3zOI6IFJlOiC72Li0OiBb ZWRrMi1kZXZlbF0gW1BBVENIIHYyXSBVZWZpQ3B1UGtnL01wSW5pdExpYjogQWRkIGNoZWNrIGZv ciBDUjMvR0RUL0lEVC4NCg0KT24gMDkvMDQvMjAgMDQ6MTgsIEZhbiBKZWZmIHdyb3RlOg0KPiBM YXN6bG8gJiBFcmljLA0KPg0KPiBJbnRyb2R1Y2luZyBvbmUgbmV3IFBDRCB0byBoYW5kbGUgc3Vj aCByYXJlIHRlc3QgY2FzZSBpcyB0b28gaGVhdnkuIEkgdGhpbmsgV2UgY291bGQgZG8gdmFsaWRh dGluZyBDUjMvR0RUL0lEVCBzcGFjZSA8IDRHQiBhZGRyZXNzIGFsd2F5cyBpbiBNcEluaXRMaWIu DQoNCkkgZGlzYWdyZWUuDQoNCldoYXQgdGhlIFVFRkkgYXBwbGljYXRpb24gZG9lcyAoaW50ZXJm ZXJlIHdpdGggR0RUIC8gSURUIC8gQ1IzDQpwbGFjZW1lbnQpIGlzIGludmFsaWQuIEl0IGNoYW5n ZXMgc3lzdGVtIHByb3BlcnRpZXMgdW5kZXIgdGhlIGZlZXQgb2YNCnBsYXRmb3JtIERYRSBkcml2 ZXJzLiBVRUZJIGFwcGxpY2F0aW9ucyBhcmUgc3VwcG9zZWQgdG8gYmUgd3JpdHRlbg0KYWdhaW5z dCBwdWJsaWMgcHJvdG9jb2xzIGFuZCBzZXJ2aWNlcyBpbiB0aGUgVUVGSSBzcGVjIChhbmQgbWF5 YmUgaW4gdGhlDQpQSSBzcGVjKS4NCg0KSWYgdGhpcyBhcHBsaWNhdGlvbiBpcyBhIHRlc3QgYXBw bGljYXRpb24gdGhhdCBwdXJwb3NlbHkgbWFzc2FnZXMNCmxvdy1sZXZlbCBzeXN0ZW0gcHJvcGVy dGllcywgdGhhdCdzIGZpbmU7IGJ1dCB0aGVuLCBpZiB3ZSBjaGFuZ2UgY29yZQ0KZWRrMiBjb21w b25lbnRzIHRvIGJlIHNvbWV3aGF0IGNvbXBhdGlibGUgd2l0aCB0aGlzIGFwcGxpY2F0aW9uLCB0 aGVuIHdlDQpzaG91bGQgbWFrZSBzdXJlIHRoYXQgcGxhdGZvcm1zIHRoYXQgZG8gbm90IGNhcmUg YWJvdXQgdGhpcyBzcGVjaWZpYyB1c2UNCmNhc2UgZG8gbm90IHN1ZmZlciBhIHBlcmZvcm1hbmNl IGhpdCBvciBhIGNvZGUgY29tcGxleGl0eSBoaXQuDQoNCldoYXQgSSBjb3VsZCBhY2NlcHQsIHVu ZGVyIHlvdXIgcHJvcG9zYWwsIGlzIHRoZSBmb2xsb3dpbmc6IGFkZCB0aHJlZQ0KQVNTRVJUKClz IHRvIEZpbGxFeGNoYW5nZUluZm9EYXRhKCksIHdoZXJlIHdlIGZldGNoIHRoZSBJRFRSIC8gR0RU UiAvDQpDUjMgYW55d2F5LiBUaGlzIHdvdWxkIGJlIGZpbmUgYmVjYXVzZSBpdCBvbmx5IGV4cHJl c3NlcyBleGlzdGluZw0KYXNzdW1wdGlvbnMgLyByZXF1aXJlbWVudHMuDQoNCkhvd2V2ZXIsIG15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIHdvdWxkIG5vdCBzb2x2ZSBFcmljJ3MgcHJvYmxl bS4NClRoZSBzeXN0ZW0gd291bGQgaGFuZyAtLSBpbiBERUJVRyAvIE5PT1BUIGJ1aWxkcyAtLSBv ciBjcmFzaCAtLSBpbiBhDQpSRUxFQVNFIGJ1aWxkIC0tIGp1c3QgdGhlIHNhbWUgYXMgYmVmb3Jl Lg0KDQpOb3csICppZiogRmlsbEV4Y2hhbmdlSW5mb0RhdGEoKSBpcyBjdXJyZW50bHkgKndyb25n KiB0byBoYXZlIHRoZXNlDQozMi1iaXQgYXNzdW1wdGlvbnMsIGJlY2F1c2UgZWRrMiBtb2R1bGVz IHRoZW1zZWx2ZXMgY2FuIGJyZWFrIHRob3NlDQphc3N1bXB0aW9ucyAod2l0aG91dCB0aGUgY3Vz dG9tIFVFRkkgYXBwbGljYXRpb24pLCB0aGVuIHdlIGhhdmUgYSBtb3JlDQpzZXJpb3VzIHByb2Js ZW0uIEJ1dCBmb3IgdGhhdCBwcm9ibGVtLCBqdXN0ICJjaGVja2luZyBhbmQgcmVqZWN0aW5nIiBp cw0Kbm90IGEgc3VmZmljaWVudCBzb2x1dGlvbiwgcmVnYXJkbGVzcyBvZiBob3cgYW5kIHdoZXJl IHdlIGNoZWNrIGFuZCByZWplY3QuDQoNClRoYW5rcw0KTGFzemxvDQoNCg0KDQoNCj4NCj4gSmVm Zg0KPg0KPiC3orz+yMs6IERvbmcsIEVyaWM8bWFpbHRvOmVyaWMuZG9uZ0BpbnRlbC5jb20+DQo+ ILeiy83KsbzkOiAyMDIwxOo51MI0yNUgMTA6MDENCj4gytW8/sjLOiBOaSwgUmF5PG1haWx0bzpy YXkubmlAaW50ZWwuY29tPjsgZGV2ZWxAZWRrMi5ncm91cHMuaW88bWFpbHRvOmRldmVsQGVkazIu Z3JvdXBzLmlvPjsgbGVyc2VrQHJlZGhhdC5jb208bWFpbHRvOmxlcnNla0ByZWRoYXQuY29tPg0K PiCzrcvNOiBMb3UsIFl1bjxtYWlsdG86eXVuLmxvdUBpbnRlbC5jb20+DQo+INb3zOI6IFJlOiBb ZWRrMi1kZXZlbF0gW1BBVENIIHYyXSBVZWZpQ3B1UGtnL01wSW5pdExpYjogQWRkIGNoZWNrIGZv ciBDUjMvR0RUL0lEVC4NCj4NCj4gSSBndWVzcyBMYXN6bG8gdGhpbmsgdGhpcyBjaGVjayBpcyBu b3QgYWx3YXlzIG5lZWRlZCwganVzdCB1c2VkIGZvciB0aGlzIHNwZWNpYWwgc2hlbGwgYXBwbGlj YXRpb24gY2FzZS4gSGUgd2FudHMgdG8gdXNlIGRlZmF1bHQgRkFMU0UgdG8gYWx3YXlzIGlnbm9y ZSB0aGlzIGNoZWNrIGFuZCBtYWtlIGNvZGUgbG9naWMgY2xlYXIuDQo+DQo+IFRoYW5rcywNCj4g RXJpYw0KPg0KPiBGcm9tOiBOaSwgUmF5IDxyYXkubmlAaW50ZWwuY29tPg0KPiBTZW50OiBGcmlk YXksIFNlcHRlbWJlciA0LCAyMDIwIDk6MzQgQU0NCj4gVG86IGRldmVsQGVkazIuZ3JvdXBzLmlv OyBsZXJzZWtAcmVkaGF0LmNvbTsgRG9uZywgRXJpYyA8ZXJpYy5kb25nQGludGVsLmNvbT4NCj4g Q2M6IExvdSwgWXVuIDx5dW4ubG91QGludGVsLmNvbT4NCj4gU3ViamVjdDogUmU6IFtlZGsyLWRl dmVsXSBbUEFUQ0ggdjJdIFVlZmlDcHVQa2cvTXBJbml0TGliOiBBZGQgY2hlY2sgZm9yIENSMy9H RFQvSURULg0KPg0KPiBXaHkgZG8gd2UgbmVlZCBhIG5ldyBQQ0QgdG8gY29udHJvbCBzdWNoIGNo ZWNrPyBVbmRlciB3aGF0IGNpcmN1bXN0YW5jZSB0aGUgUENEIGlzIGZhbHNlPw0KPiBXZSBtYXkg bmVlZCB0byBtb3ZlIHN1Y2ggY2hlY2sgb3V0IG9mIE1wTGliLmMuIEJlY2F1c2Ugd2hlbiBicHMg cnVucyBhdCAzMmJpdCBtb2RlLCBBUCBkb2VzbqGvdCBuZWVkIHRvIHN3aXRjaCB0byBsb25nIG1v ZGUsIHN1Y2ggY2hlY2sgaXMgbm90IG5lZWRlZCBhbmQgYWxzbyBhbHdheXMgcGFzc2VzLg0KPg0K PiBXZSBzaG91bGQgbm90IGFzc3VtZSBQRUkgcnVucyBhdCAzMiBiaXQgbW9kZS4NCj4NCj4NCj4g t6K8/sjLOiBkZXZlbEBlZGsyLmdyb3Vwcy5pbzxtYWlsdG86ZGV2ZWxAZWRrMi5ncm91cHMuaW8+ IDxkZXZlbEBlZGsyLmdyb3Vwcy5pbzxtYWlsdG86ZGV2ZWxAZWRrMi5ncm91cHMuaW8+PiC0+rHt IExhc3psbyBFcnNlayA8bGVyc2VrQHJlZGhhdC5jb208bWFpbHRvOmxlcnNla0ByZWRoYXQuY29t Pj4NCj4gt6LLzcqxvOQ6IEZyaWRheSwgU2VwdGVtYmVyIDQsIDIwMjAgMzo1NTo0NyBBTQ0KPiDK 1bz+yMs6IERvbmcsIEVyaWMgPGVyaWMuZG9uZ0BpbnRlbC5jb208bWFpbHRvOmVyaWMuZG9uZ0Bp bnRlbC5jb20+PjsgZGV2ZWxAZWRrMi5ncm91cHMuaW88bWFpbHRvOmRldmVsQGVkazIuZ3JvdXBz LmlvPiA8ZGV2ZWxAZWRrMi5ncm91cHMuaW88bWFpbHRvOmRldmVsQGVkazIuZ3JvdXBzLmlvPj4N Cj4gs63LzTogTmksIFJheSA8cmF5Lm5pQGludGVsLmNvbTxtYWlsdG86cmF5Lm5pQGludGVsLmNv bT4+DQo+INb3zOI6IFJlOiBbZWRrMi1kZXZlbF0gW1BBVENIIHYyXSBVZWZpQ3B1UGtnL01wSW5p dExpYjogQWRkIGNoZWNrIGZvciBDUjMvR0RUL0lEVC4NCj4NCj4gT24gMDkvMDMvMjAgMjE6MDAs IExhc3psbyBFcnNlayB3cm90ZToNCj4NCj4+ICgxMCkgTW9yZSBpbXBvcnRhbnRseSwgVmFsaWRD UjNHZHRJZHRDaGVjaygpIHNob3VsZCBub3QgYmUgY2FsbGVkIGluIHRoZQ0KPj4gV29ya2VyIGZ1 bmN0aW9ucyBmb3IgU3RhcnR1cEFsbEFQcywgU3RhcnR1cFRoaXNBUCwgU3dpdGNoQlNQLCBhbmQN Cj4+IEVuYWJsZURpc2FibGVBUCwgaW4gIlVlZmlDcHVQa2cvTGlicmFyeS9NcEluaXRMaWIvTXBM aWIuYyIuDQo+Pg0KPj4gSW5zdGVhZCwgdGhlIGNhbGxzIHNob3VsZCBiZSBtYWRlIGluIHRoZSBE WEUgaW5zdGFuY2Ugb2YgdGhlIGxpYnJhcnkNCj4+ICgiVWVmaUNwdVBrZy9MaWJyYXJ5L01wSW5p dExpYi9EeGVNcExpYi5jIiksIGF0IHRoZSB2ZXJ5IHRvcCBvZiB0aGUNCj4+IGZ1bmN0aW9uczoN Cj4+DQo+PiAtIE1wSW5pdExpYlN0YXJ0dXBBbGxBUHMNCj4+IC0gTXBJbml0TGliU3RhcnR1cFRo aXNBUA0KPj4gLSBNcEluaXRMaWJTd2l0Y2hCU1ANCj4+IC0gTXBJbml0TGliRW5hYmxlRGlzYWJs ZUFQDQo+Pg0KPj4gSGVyZSdzIHdoeToNCj4+DQo+PiAoYSkgVGhlIHN5bXB0b20gZG9lcyBub3Qg YWZmZWN0IHRoZSBQRUkgcGhhc2UgLS0gYnkgdGhlIHRpbWUgdGhlIFVFRkkNCj4+IGFwcGxpY2F0 aW9uIGlzIGV4ZWN1dGVkLCB0aGUgUEVJIHBoYXNlIGhhcyBlbmRlZDsgdGhlcmUncyBubyBuZWVk IHRvDQo+PiBtb2RpZnkgdGhlIFBFSSBpbnN0YW5jZSBvZiB0aGUgbGlicmFyeS4NCj4+DQo+PiAo YikgVGhlIGN1cnJlbnRseSBwcm9wb3NlZCBmYWlsdXJlIGV4aXRzIGFyZSB0b28gbGF0ZS4gRm9y IGV4YW1wbGUsIGluDQo+PiB0aGUgU3dpdGNoQlNQV29ya2VyKCkgZnVuY3Rpb24sIGJ5IHRoZSB0 aW1lIHdlIGV4aXQsIHdlIGhhdmUgY2FsbGVkDQo+PiBEaXNhYmxlQXBpY1RpbWVySW50ZXJydXB0 KCksIFNhdmVBbmREaXNhYmxlSW50ZXJydXB0cygpLCBhbmQNCj4+IERpc2FibGVMdnRJbnRlcnJ1 cHRzKCkgLS0gYW5kIHRoZSBlcnJvciBwYXRoIGRvZXMgbm90IHJlc3RvcmUgdGhlDQo+PiBvcmln aW5hbCBlbnZpcm9ubWVudC4NCj4+DQo+PiAoYykgQWNjb3JkaW5nIHRvIHRoZSBQSSBzcGVjICh2 MS43KSwgdGhlIFN0YXJ0dXBBbGxBUHMoKSwNCj4+IFN0YXJ0dXBUaGlzQVAoKSwgU3dpdGNoQlNQ KCksIEVuYWJsZURpc2FibGVBUCgpIG1lbWJlciBmdW5jdGlvbnMgb2YNCj4+IEVGSV9NUF9TRVJW SUNFU19QUk9UT0NPTCBtYXkgb25seSBiZSBjYWxsZWQgb24gdGhlIChjdXJyZW50KSBCU1AuDQo+ PiBCZWNhdXNlIG9mIHRoaXMsIGl0IGlzIE9LIHRvIGNhbGwgVmFsaWRDUjNHZHRJZHRDaGVjaygp IGFzIHRoZSB2ZXJ5DQo+PiBmaXJzdCBhY3Rpb24gaW4gdGhlIGFib3ZlLWxpc3RlZCBEeGVNcExp YiBmdW5jdGlvbnMuDQo+Pg0KPj4gKEFzc3VtaW5nIHRoZSBwcm90b2NvbCBtZW1iZXJzIGFyZSBj YWxsZWQgZnJvbSBhbiBBUCwgYW5kIGNvbnNlcXVlbnRseQ0KPj4gd2UgY2hlY2sgQ1IzIC8gR0RU UiAvIElEVFIgb24gdGhlIEFQIChhbmQgbm90IG9uIHRoZSBCU1ApLCB0aGF0J3MgdGhlDQo+PiAq Y2FsbGVyJ3MqIGZhdWx0LCBwZXIgc3BlYyEpDQo+DQo+IFRoaXMgbWVhbnMgd2UgY2FuIG1vdmUg dGhlIFZhbGlkQ3IzR2R0SWR0Q2hlY2soKSBmdW5jdGlvbiB0bw0KPiAiRHhlTXBMaWIuYyIsIGFu ZCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIG1vZGlmeSAiTXBMaWIuaCIuDQo+DQo+IFRoYW5rcw0K PiBMYXN6bG8NCj4NCj4gDQo+DQoNCg== --_000_MWHPR19MB0030EAA3D5A79EA327DDE793D72D0MWHPR19MB0030namp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Laszlo,

 

Why sync the BSP=A1=AFs CR3/GD= T/IDT values for AP when AP wakes up instead of using old cached BSP=A1=AFs= CR3/GDT/IDT values when CPU driver initiallly dispatched is that we CANNOT= assume original values are still valid during POST phase.

 

On this senario, BSP=A1=AFs CR= 3/GDT/IDT are just like input parameters for one function. Validating them = are necessary.

 

For example, DebugAgentDxe dri= ver may be loaded in UEFI shell to setup source level debugging enviroment = of EDKII debugger tools.  It may setup new IDT space.

 

Jeff

 

=B7=A2=BC=FE= =C8=CB: Laszlo Ersek=
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA9=D4=C24=C8=D5 14:58
=CA=D5=BC=FE=C8=CB: Fan Jeff; devel@edk2.groups.io; eric.dong@intel.com; Ni, Ray =B3=AD=CB=CD: Lou, Yun
=D6=F7=CC=E2: Re: =BB=D8=B8=B4: [edk2-devel] [PATCH v2] Ue= fiCpuPkg/MpInitLib: Add check for CR3/GDT/IDT.

 

On 09/04/20 04:18, Fan Jeff wrote:
> Laszlo & Eric,
>
> Introducing one new PCD to handle such rare test case is too heavy. I= think We could do validating CR3/GDT/IDT space < 4GB address always in = MpInitLib.

I disagree.

What the UEFI application does (interfere with GDT / IDT / CR3
placement) is invalid. It changes system properties under the feet of
platform DXE drivers. UEFI applications are supposed to be written
against public protocols and services in the UEFI spec (and maybe in the PI spec).

If this application is a test application that purposely massages
low-level system properties, that's fine; but then, if we change core
edk2 components to be somewhat compatible with this application, then we should make sure that platforms that do not care about this specific use case do not suffer a performance hit or a code complexity hit.

What I could accept, under your proposal, is the following: add three
ASSERT()s to FillExchangeInfoData(), where we fetch the IDTR / GDTR /
CR3 anyway. This would be fine because it only expresses existing
assumptions / requirements.

However, my understanding is that this would not solve Eric's problem.
The system would hang -- in DEBUG / NOOPT builds -- or crash -- in a
RELEASE build -- just the same as before.

Now, *if* FillExchangeInfoData() is currently *wrong* to have these
32-bit assumptions, because edk2 modules themselves can break those
assumptions (without the custom UEFI application), then we have a more
serious problem. But for that problem, just "checking and rejecting&q= uot; is
not a sufficient solution, regardless of how and where we check and reject= .

Thanks
Laszlo




>
> Jeff
>
> =B7=A2=BC=FE=C8=CB: Dong, Eric<mailto:eric.don= g@intel.com>
> =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA9=D4=C24=C8=D5 10:01
> =CA=D5=BC=FE=C8=CB: Ni, Ray<mailto:ray.ni@intel.com>; devel@edk2.groups.io<mailto:devel= @edk2.groups.io>; lersek@redhat.com<mailto:lersek@redhat.com>
> =B3=AD=CB=CD: Lou, Yun<mailto:yun.lou@intel.com>
> =D6=F7=CC=E2: Re: [edk2-devel] [PATCH v2] UefiCpuPkg/MpInitLib: Add check for CR3/G= DT/IDT.
>
> I guess Laszlo think this check is not always needed, just used for t= his special shell application case. He wants to use default FALSE to always= ignore this check and make code logic clear.
>
> Thanks,
> Eric
>
> From: Ni, Ray <ray.ni@intel.com>
> Sent: Friday, September 4, 2020 9:34 AM
> To: devel@edk2.groups.io; lersek@redhat.com; Dong, Eric <eric.dong= @intel.com>
> Cc: Lou, Yun <yun.lou@intel.com>
> Subject: Re: [edk2-devel] [PATCH v2] UefiCpuPkg/MpInitLib: Add check = for CR3/GDT/IDT.
>
> Why do we need a new PCD to control such check? Under what circumstan= ce the PCD is false?
> We may need to move such check out of MpLib.c. Because when bps runs = at 32bit mode, AP doesn=A1=AFt need to switch t= o long mode, such check is not needed and also always passes.
>
> We should not assume PEI runs at 32 bit mode.
>
>
> =B7=A2=BC=FE=C8=CB: devel@edk2.groups.io&= lt;mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel= @edk2.groups.io>> =B4=FA=B1=ED Laszlo Ersek <lersek@redhat.co= m<mailto:lersek@redhat.com>>
> =B7=A2=CB=CD=CA=B1=BC=E4: Friday, Septemb= er 4, 2020 3:55:47 AM
> =CA=D5=BC=FE=C8=CB: Dong, Eric <eric.d= ong@intel.com<mailto:eric.dong@intel.com>>; devel@edk2.groups.io&l= t;mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@= edk2.groups.io>>
> =B3=AD=CB=CD: Ni, Ray <ray.ni@intel.co= m<mailto:ray.ni@intel.com>>
> =D6=F7=CC=E2: Re: [edk2-devel] [PATCH v2]= UefiCpuPkg/MpInitLib: Add check for CR3/GDT/IDT.
>
> On 09/03/20 21:00, Laszlo Ersek wrote:
>
>> (10) More importantly, ValidCR3GdtIdtCheck() should not be called= in the
>> Worker functions for StartupAllAPs, StartupThisAP, SwitchBSP, and=
>> EnableDisableAP, in "UefiCpuPkg/Library/MpInitLib/MpLib.c&qu= ot;.
>>
>> Instead, the calls should be made in the DXE instance of the libr= ary
>> ("UefiCpuPkg/Library/MpInitLib/DxeMpLib.c"), at the ver= y top of the
>> functions:
>>
>> - MpInitLibStartupAllAPs
>> - MpInitLibStartupThisAP
>> - MpInitLibSwitchBSP
>> - MpInitLibEnableDisableAP
>>
>> Here's why:
>>
>> (a) The symptom does not affect the PEI phase -- by the time the = UEFI
>> application is executed, the PEI phase has ended; there's no need= to
>> modify the PEI instance of the library.
>>
>> (b) The currently proposed failure exits are too late. For exampl= e, in
>> the SwitchBSPWorker() function, by the time we exit, we have call= ed
>> DisableApicTimerInterrupt(), SaveAndDisableInterrupts(), and
>> DisableLvtInterrupts() -- and the error path does not restore the=
>> original environment.
>>
>> (c) According to the PI spec (v1.7), the StartupAllAPs(),
>> StartupThisAP(), SwitchBSP(), EnableDisableAP() member functions = of
>> EFI_MP_SERVICES_PROTOCOL may only be called on the (current) BSP.=
>> Because of this, it is OK to call ValidCR3GdtIdtCheck() as the ve= ry
>> first action in the above-listed DxeMpLib functions.
>>
>> (Assuming the protocol members are called from an AP, and consequ= ently
>> we check CR3 / GDTR / IDTR on the AP (and not on the BSP), that's= the
>> *caller's* fault, per spec!)
>
> This means we can move the ValidCr3GdtIdtCheck() function to
> "DxeMpLib.c", and it is not necessary to modify "MpLib= .h".
>
> Thanks
> Laszlo
>=20 >

 

--_000_MWHPR19MB0030EAA3D5A79EA327DDE793D72D0MWHPR19MB0030namp_--