From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=15.233.44.27; helo=g2t2354.austin.hpe.com; envelope-from=brian.johnson@hpe.com; receiver=edk2-devel@lists.01.org Received: from g2t2354.austin.hpe.com (g2t2354.austin.hpe.com [15.233.44.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 673B22035261A for ; Thu, 26 Oct 2017 13:45:11 -0700 (PDT) Received: from G9W8456.americas.hpqcorp.net (g9w8456.houston.hp.com [16.216.161.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2354.austin.hpe.com (Postfix) with ESMTPS id 18DF8DC; Thu, 26 Oct 2017 20:48:57 +0000 (UTC) Received: from G9W8454.americas.hpqcorp.net (2002:10d8:a104::10d8:a104) by G9W8456.americas.hpqcorp.net (2002:10d8:a15f::10d8:a15f) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 26 Oct 2017 20:48:25 +0000 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (15.241.52.12) by G9W8454.americas.hpqcorp.net (16.216.161.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4 via Frontend Transport; Thu, 26 Oct 2017 20:48:25 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=brian.johnson@hpe.com; Received: from [10.0.2.15] (192.48.192.5) by AT5PR8401MB0403.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:741e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 20:48:19 +0000 To: "Dong, Eric" , Laszlo Ersek , "edk2-devel@lists.01.org" CC: "Ni, Ruiyu" , Paolo Bonzini References: <1508743358-3640-1-git-send-email-eric.dong@intel.com> <1508743358-3640-3-git-send-email-eric.dong@intel.com> <4fe39a52-0cd3-de2e-84f2-7363823a1b60@redhat.com> <1329f926-4c33-aaca-108a-7d15ae0503bc@redhat.com> <94c27429-4b7d-6c21-c1e5-e07f3e9a5556@redhat.com> From: "Brian J. Johnson" Message-ID: <7c0023c7-01cb-e4a2-2c6a-c93372e651a4@hpe.com> Date: Thu, 26 Oct 2017 15:48:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [192.48.192.5] X-ClientProxiedBy: MWHPR2201CA0069.namprd22.prod.outlook.com (2603:10b6:301:5e::22) To AT5PR8401MB0403.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:741e::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: eacda617-5b69-48b5-7b44-08d51cb2e61f X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AT5PR8401MB0403; X-Microsoft-Exchange-Diagnostics: 1; AT5PR8401MB0403; 3:7vHD6uyKD61dVLg2wIlHKxYsKxGZAX8072n6FW44wTsGw83ipA0ijguh8UUp0d1COWoZWHJiVItqQ5PBfK96QBG5J/rj/toPp8UTHQCe+22EMZlwi+CaVexTQM5+bnWwrTuguueRPD+XBaUQ5iiwF5tM2Q8g0HYmif4lYU9ZSEXQUKL5dRfDh3dUjmAKRmyGsSmlXZiaKGTZ6FPNuFTsI0XnJZcCpQX/uvrN4BFPKvAw0jEoXHhIr6x9W6ZKY2RE; 25:apUo/6jISsQlVKTyUuZdqLI3++gsA+JxstEmjMHlMObTTmyxXg/sj3FsAnEIrt2bucgbl0MfWLU3w4a4rC51gFBPjFl20g76CVwtIZdstdUJ+kiUc3HLHsULXPNXGAu52/JZW1o4wU2Pm6DZcHNsVjFGtKsuq6CEgjigAM639zgQ25u/Rby80RkRTNUcNzC7dIPcLQGhLkWVrMBNV7fZSuwgBEtGhOW0gXyuqYNQ/hOO+M36D+yDd4W6cuyRPrS8BMo4yCnuPgeeki7XMoBSdfuWJvLFpoMbvnUSyslSzRjpCymEKB1UWY+0KDUurw7L9nAOQUwksfpaIv/R9NSFJQ==; 31:NO5GV8w8aSknluaj4hEDatTsR+xpZah0mIamAGfa357A3C6C4NahEojM4Vy8d0OLcueWlDg6IQFRrbYNWvpHmM/4Gytnal4fFGqbPTRuf1bvqXPzhQRuNc7Gcy3AQnprb2+zy2QwzF39hT/18g4YuZVkAaARyeHbPwoKOg//ZsC4BLqJ6ierBIxK3SH9f7PvlQr5Usk3tMWcQJ+PFbpiuqYstE4Xrpd/Zg3ZMDwuYWw= X-MS-TrafficTypeDiagnostic: AT5PR8401MB0403: X-Microsoft-Exchange-Diagnostics: 1; AT5PR8401MB0403; 20:RDFfH1rBWtyfKNajVBAdNv+Wg+/a9itY/VXpR5Qhj5P9ZM2AUP6M5XAP0JhQ2xhNZDM8kbxawzdGO42fOLobUY4RCGAFZdY8bSk9H6yYGCVfZ5SLDJBuvMh3Nxf3W7j3Z8AIeaoNteaQacqGCz5D8/A/ARZNKF6SRRz7Ut+U07Q8VCgeMKFxjY4IRFVAQENqGPrIRLsIM5RmqdcwaGG117Q5eDftLDp5oOUgaZv65zTao1IgxWEzDGcRVywOSU/0TbNvFaDz+hFYRc5ABeAi41viSJtHp1EHgxX6mhPS70Q9Wk91hqsv4ACnbHrTyphj8T5i8+uE43amJYoiG4XCi/2ctLBb+I2WzNaJ42sAEr3/FdTZhiVzqbyxhaTUJydISv6Unptax/X8Gbbf6duhFOMJQoyeSWuOzguCcdVHpXHNODecEHs104iTYXvZe3NXrK2TNwDYECkFJdnGIRZzxusstCsYQFngzrEb867WX2ZKS8ugnuaWIii2VeR1vuS4; 4:WLEndBywnFQfpfFB1qY3rs2Z0utwcBAtKjHreZtihyeMnx5BdhY6TV4zYJHP9SohvRCzqISuf2mv4xL5cZhRWDTHIG0dxPnfdn8K4WcPpesLslydACfAnLC6901YDiVRoG2M1zNc/KTISgFAyE7GrEIArJDMY+tclBjzAlWs7kHRjYvKmSLEW75ohlKoQdOGzqcosHaczK41/ScIuteHgdMyOjCSUK+BLeVEMf1NchuJsT3subDzJuQ0W0RIPlZL+E6YRWCvgA0HpH044cEC9qrupCo/YD2t3aWWZidLmG2EwIDvxx6lgqqAMoiUyFDlAjMeN6EeJzJJ5BhHoTKE1g== X-Exchange-Antispam-Report-Test: UriScan:(162533806227266)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3231020)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AT5PR8401MB0403; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AT5PR8401MB0403; X-Forefront-PRVS: 04724A515E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(6029001)(6049001)(346002)(376002)(39860400002)(24454002)(199003)(13464003)(189002)(6666003)(23676002)(189998001)(106356001)(93886005)(53546010)(6486002)(68736007)(8936002)(105586002)(97736004)(6116002)(230700001)(3846002)(2501003)(229853002)(77096006)(53936002)(2906002)(16526018)(316002)(54906003)(50466002)(50986999)(101416001)(76176999)(54356999)(86362001)(5660300001)(6306002)(7736002)(478600001)(47776003)(31686004)(110136005)(305945005)(83506002)(6246003)(65826007)(16576012)(58126008)(966005)(4326008)(64126003)(25786009)(65956001)(33646002)(2950100002)(31696002)(81166006)(81156014)(65806001)(8676002)(66066001)(36756003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR8401MB0403; H:[10.0.2.15]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBVDVQUjg0MDFNQjA0MDM7MjM6VWdLaFhnUGpZSlpxd25YbndjbzBrS2VL?= =?utf-8?B?MmNkVXB5dEg4eEE3N3RuMDlva3NRSFo2VDhmTllydVU0a2xqZmY1bllSdnM0?= =?utf-8?B?WGMrYit1UUNJUGx3Z1dpSEJHcWtwM2VQQ3JwZkw4OUlxbWNPR2VieGlmT3RL?= =?utf-8?B?RHN4bld3SnBTSnRieHhuYXc2RXFYcTRXRlBxc09oMndxUEw1ZEEwSDFFSEFo?= =?utf-8?B?TFpWQk8wb25aSjVUMFRidEdSaHJ5NFRwYXpITVdubTJvYXNYbVd6T3ZVQTN4?= =?utf-8?B?LzNlWllzT0hobkR0TEVlYTlRNVFTRHZnMmVXTUkrUnVvNlRZaFRwV2JzNklR?= =?utf-8?B?bGJtRzB1QTQ3akY2dEFaTmxsNEIycFdSSDVSVzYvbkJPVmtuSzA1VkhuWW1W?= =?utf-8?B?NFZZblpQOXBUaG9tWU1CVzBXN3ppMFpoTUNxejQ0NzV0eFF2UkkwNGNtOC9y?= =?utf-8?B?ZjUvWWpJYU5DNEJTei9WcG5tOHBKSVpYQUlFeDBFWktCTWROa04rS2EzTVNX?= =?utf-8?B?NWdxUXdSY1hFQ1VrVHFlOXowU3czaGZrcU5yQVRFWTl4SkVIdmVOTlhBRUVH?= =?utf-8?B?RWVSa0FKKzJ0OWZGNWNOQ2tReW1rMDFBZzQxb09lVzdyaGxDb0NublZJNHVD?= =?utf-8?B?eG5qdVNTVkNRNEJybklMU0tzckdrbFh2QWNQQncxeG44SUFMMTc1M2RMWTJF?= =?utf-8?B?VmJSZ2piNnJJelA0RE1kRGpoWFdZeElyK1ZlbnVsWWZWOFNDU1lpLytidHFl?= =?utf-8?B?aEdVeElJMUlRU1NrWnFKb2VjSjFITkxNMU90OE9sbjA1blI2QlJDdGs2blBk?= =?utf-8?B?SEUwWGg1VTNyRUJFanMrWjJuS1QxTm0wQml4MjFnMVZPdlQ1eUtSUzkwVjlx?= =?utf-8?B?UEl2VUVFRzJhMVJ2VmZXZFU4TFlzNUwyZ3pNa1NmcGVhdElCdWdFZ3BtQ3V4?= =?utf-8?B?ODJsMm81anB3SzA4d3piR1VuMVczcHIyaTFqbm1zVWJONGordUFUNXFEL1ZO?= =?utf-8?B?ZFJNT0dJRnZpN0lrMnhvOVNiRmhkdDNvaFFSUmJUZjAyOGZTT2lmSXhjczBz?= =?utf-8?B?YjAwVTk2SFRWa2lMTWxVeVBPbVpESk1rdS9DUzZnb0laOUFXK0tlR2tZY29h?= =?utf-8?B?V09xWTJkUkxnNGRlYUJUNjNFTmN2ZWtlcytEcTVJcFE2b2hPbFpZQWxKa2wr?= =?utf-8?B?VjVyMmhoZklXaEd0OGcvQ1k5ZldnemQ2MEJ4UzhXbDhMcjk2Y1F5RlNYOHpZ?= =?utf-8?B?UkNuYVpXeUNVd3pMTFR5MTJCN3lnaTBCeTVMeFFteE5mL2IxZUhPbHRmR0Vj?= =?utf-8?B?RWZLV2R2K01GVmZleDB0SVRWWDRQdHlUVzdBVnRCYkJkcXc5R1Zkd2M4a0tC?= =?utf-8?B?R2R5MTRSaVBKWkJNZkw0ZWxSOHdjaHgvdU9NeGdGYjkxVytPa0g1OTBCUXUz?= =?utf-8?B?TXF4MGFJTjIyNHRCNmoyUGszOSt6TC9CTGtYUmg3VWZrV2dCdFcxVytUc0g4?= =?utf-8?B?am91TGFOWkZ6ZFJSM0pRRTg0dlRFOVFJYmVBODVCaU05RE02cDJjSU94UVJj?= =?utf-8?B?YTF0djk1cEdKaFlvS3h2aXdRNDNZbkg1V0lPK1pLeHFKa25PLzVTUS9KNlFF?= =?utf-8?B?NlNtRklmVE5NSUFTaHpCT1cxd2NaNlcxbVNUUVkxWHVmNFRXU0o2WlFGc1NS?= =?utf-8?B?bmp3R2VrZjNsT29CRW82ZkJqZlExeDR3eGk3M2J3TnBKNGY5bFZ6dGQvbDBL?= =?utf-8?B?ZVpUZE12S2pZOHA5Rlc2MFB4NlJRa1h1OW9MeHovcXdEM3F4SEFKaXBTZ1ZT?= =?utf-8?B?VlBaUG1EaDZlWko1MWp3ZEJlb21lOThRTnN0NVJMVkVNWFAvQW15Ym5MbWht?= =?utf-8?B?NVBWdzE4REpJVkJZYUhmVXNMYmtLYzRlTC9jRWtsUlNvV3RrU29GQnFoSmsr?= =?utf-8?B?Q0liRUxhekVzQjBWR01kbmdYaUZFZnYvclJlb29odjRMWGNmdHNPREViZjNT?= =?utf-8?B?VlhaMzFmOXlaOWNtM3RVNVllQmZiLzRGSmw5USttWEpJN3dnMXFjNTgyVDAz?= =?utf-8?B?UWVQLzZVZG5CNlFuOXl3bklLYWdLK1JDZi9lK1I5UC9IaXpwcHFoMXJ2blB2?= =?utf-8?Q?MeqK920fmBO2sfO0RjJs1Ctj0=3D?= X-Microsoft-Exchange-Diagnostics: 1; AT5PR8401MB0403; 6:LM3x9T+nhWXYtUoCESzerdSGCklN23H1D0yMJGuI81A0o5+hQYNCsEAu5UwnCcoJUA6RwqlwqgRO5bO8O7RgAe1VU3ce0N4AgzlCRTZXwi9BH1x2UOCzQy6Ocgfa/KwZdtU/XrOWnsFAVL/3A+ATqWh5TgJDYISX/XtrFqUxj61qp9cMVQUWwTz3WizFXbnvJHTLn+D15bpSNPyz+JjTrx1aLDKCiJtL1jy9BYGUA5M5slCypecHCwxmVdrhAW41/PZOBfk6ZNDmOYx8hgk0+CRSQiUdJsxllZTBuit7805zOigS3nZAGj864I5YWMo7FJCBMwI92JGiw8ObUNE3aw==; 5:ynF1PrILQ5WaqErhtkqtPZmMKBNx8YP+8IzBnhNpePWLRGYYydPaGcjzky4oynNulYmiEW1Lg3fqy0hl4KTl9B+LkglvndDVFIW+SKenVboIHQIxz7INFwvOYwwRNezWNzrEtMeo5DdbZglWRhQAjw==; 24:xJRallNsPV8YUcZcY0HuPaIEI4X9dkkNqhfW4f4YZtxVc0yJQgbVzJU8XRr2rbdwScosN7nPF50q7tS3rR7SQSRHikjpLk3j5glYHuc33VY=; 7:OKTJB9QfFvEz8QJ/k1C7qNPySrXbcNb1Rn2+5+1zk1/DjSk1LWhRym136Vfg0iXpDvysh2j/GM3/e7nor4dB2JC+/EQ0nxUvOKCThly+0th7niHqWl1QvTsqr3jwkMlWepHY+XU0vrjNnwLXAFJMw8T6KBUxLIZ4kvhh4b6x1oVN2h1+L4Le5Y4c+v6GUfFditQa4WGd0wAXULuV6ocOEYjwGB5CUz3/xlqKHNrB9u0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2017 20:48:19.5247 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: eacda617-5b69-48b5-7b44-08d51cb2e61f X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB0403 X-OriginatorOrg: hpe.com Subject: Re: [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for AP initialization logic. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 20:45:11 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/25/2017 08:13 PM, Dong, Eric wrote: > Laszlo, > > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >> Laszlo Ersek >> Sent: Wednesday, October 25, 2017 11:08 PM >> To: Dong, Eric ; edk2-devel@lists.01.org >> Cc: Ni, Ruiyu ; Paolo Bonzini >> Subject: Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for >> AP initialization logic. >> >> Hi Eric, >> >> On 10/25/17 07:42, Dong, Eric wrote: >>> Hi Laszlo, >>> >>> I think I have clear about your raised issues for Ovmf platform. In this case, I >> think your platform not suit for this code change. How about I do below >> change based on the new code: >>> >>> - if (CpuMpData->CpuCount == 0) { >>> TimedWaitForApFinish ( >>> CpuMpData, >>> PcdGet32 (PcdCpuMaxLogicalProcessorNumber) - 1, >>> PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds) >>> ); >>> - } >>> >>> After this change, for Ovmf can still set >>> PcdCpuApInitTimeOutInMicroSeconds to MAX_UINT32 to keep old >> solution. >>> For the real platform, it can set a small value to follow the new >>> solution. For this new change, it just wait one more >>> PcdCpuApInitTimeOutInMicroSeconds timeout, should not have >> performance >>> impact (This time may also been cost in later while >>> (CpuMpData->MpCpuExchangeInfo->NumApsExecuting != 0) loop) or have >>> litter performance impact (not cover by the later loop). >> The suggested change will work for OVMF, thanks! >> >> (Just please don't forget to un-indent the TimedWaitForApFinish() call that >> will become unconditional again.) >> >> --o-- >> >> Do you think Brian's concern should be investigated as well (perhaps in a >> separate Bugzilla entry)? > > As Jeff has mentioned, only Ovmf can know the exist Ap numbers before > send the Init-sipi-sipi. So we don't know how many bits needed for this bitmap. > In case we can create the bitmap, we still don't know when all Aps have been > found(If the begin map bit value same as finish map bit value, we still can't get > the conclusion that all Aps have been found, because maybe other Aps not > started yet). > Right, physical platforms don't usually know the number of CPUs up front, so they still need a timeout. That's unavoidable. But we've seen cases where interrupts aren't getting delivered reliably, so not all the expected CPUs start up (based on the core counts in the physical sockets, as known by the developing engineer, not the firmware.) To debug this failure, it's very useful to have a list of exactly which CPUs did start. Similarly, we've seen cases where a CPU starts, but crashes due to h/w or s/w bugs before signaling the BSP that it has finished. With only a counter to indicate how many CPUs are still running, it's impossible to tell which CPUs failed. That makes debugging much more difficult. The bitmaps would need to be sized according to the maximum number of CPUs supported by the platform (or the maximum APIC ID, depending on how they are indexed), like other data structures in the MpCpu code. Bitmaps aren't the only possible implementation of course.... My point is that it's useful to have a list of which CPUs started executing, and which finished. > Thanks, > Eric >> >> Because, I believe, the scheduling pattern that I described earlier could be >> possible on physical platforms as well, at least in theory: >> >>>> (2) After at least one AP has started running, the logic expects >>>> "NumApsExecuting" to monotonically grow for a while, and then to >>>> monotonically decrease, back to zero. For example, if we have 1 BSP >>>> and >>>> 7 APs, the BSP logic more or less expects the following values in >>>> "NumApsExecuting": >>>> >>>> 1; 2; 3; 4; 5; 6; 7; >>>> 6; 5; 4; 3; 2; 1; 0 >>>> >>>> >>>> While this may be a valid expectation for physical processors (which >>>> actually run in parallel, in the physical world), in a virtual machine, it is not >> guaranteed. >>>> Dependent on hypervisor scheduling artifacts, it is possible that, >>>> say, three APs start up *and finish* before the remaining four APs >>>> start up *at all*. The INIT-SIPI-SIPI marks all APs for execution / >>>> scheduling in the hypervisor, yes, but the actual code execution may >>>> commence a lot later. For example, the BSP may witness the following >> series of values in "NumApsExecuting": >>>> >>>> 1; 2; 3; >>>> 2; 1; 0; >>>> 1; 2; 3; 4; >>>> 3; 2; 1; 0 >>>> >>>> and the BSP could think that there are 3 APs only, when it sees the >>>> first 0 value. >> >> I don't know if such a pattern is "likely", "unlikely", or "extremely unlikely" on >> physical platforms. I think the pattern is "theoretically possible" at least. >> >> I suggest that we go ahead with the small patch for the OVMF use case first, >> and then open a new BZ if Brian thinks there's a real safety problem with the >> code. >> > > We also notice this theoretical problem when we implement this change, but > We think this is rarely to happen on physical platforms. We think the value for > the change is much bigger than not do this change because of this theoretical > problem. I strongly disagree. Any chance for it to happen on physical platforms is too large of a chance. There's simply too much variance between physical platforms to make assumptions about interrupt delivery and the interleaving of atomic operations among dozens (or thousands!) of CPUs. With the latest change from Eric above, we can restore the old behavior by setting PcdCpuApInitTimeOutInMicroSeconds large enough to cover all APs. So the new behavior is just an optimization which a platform can enable if its timing characteristics are suitable for it. That should work. Thanks, Brian > > Thanks, > Eric >> ... I should note that, with the small patch that's going to fix the OVMF use >> case, the previous behavior will be restored for *all* platforms that continue >> using their previous PCD values. >> >> The cumulative effect of commit 0594ec417c89 and the upcoming patch will >> be that a platform may significantly decrease >> "PcdCpuApInitTimeOutInMicroSeconds", if it chooses to, and then the >> "NumApsExecuting" loop will take the role of the preexisting >> TimedWaitForApFinish() call. If a platform doesn't want that, then it should >> keep its "PcdCpuApInitTimeOutInMicroSeconds" as high as before, and then >> any implementation details in the "NumApsExecuting" loop will be irrelevant. >> >> Thanks! >> Laszlo >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > -- Brian -------------------------------------------------------------------- "This isn't a design, it's a hack." -- Stephen Gunn