From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.100; helo=mga07.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 06AD2202E5458 for ; Fri, 29 Jun 2018 02:36:10 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2018 02:36:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,285,1526367600"; d="scan'208";a="70968264" Received: from ray-dev.ccr.corp.intel.com (HELO [10.239.9.4]) ([10.239.9.4]) by orsmga002.jf.intel.com with ESMTP; 29 Jun 2018 02:35:46 -0700 To: Laszlo Ersek Cc: edk2-devel@lists.01.org References: <20180625025402.201636-1-ruiyu.ni@intel.com> <4DFBB17A-3FCF-448D-B8F0-C4D66A33CF9F@apple.com> From: "Ni, Ruiyu" Message-ID: <8f4d9fdf-a437-d8e0-cd42-ce968cbc87c1@Intel.com> Date: Fri, 29 Jun 2018 17:36:09 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Subject: Re: [PATCH] UefiCpuPkg/MpInitLib: AP uses memory preceding IDT to store CpuMpData X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:36:11 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit On 6/27/2018 8:00 PM, Laszlo Ersek wrote: > Roughly, I figured that we could set the pre-IDT pointer on the BSP, > *before* starting up the APs, to a mapping table. The mapping table > would consist of two columns, the first containing the APIC ID (of each > CPU), the second containing AP-specific pointer values. Then, after > starting up the APs, each AP could locate its own row (based on APIC ID) > in the table, and the context pointer that belongs to it. > > But, this is likely not useful, as we want to expose just the same one > pointer value to all APs together. > >>> - or else, we should stick with the current idea, but use atomic >>>    compare-and-swap operations, so that the original PEI services pointer >>>    value be restored ultimately, at the least, >> I like this idea. Will generate the V2 patch. I finally give up on this direction. The basic idea of this approach is there is a master AP and many other slave APs. The master AP is responsible to save CpuMpData to PeiServices pointer location, the restores PeiServices pointer back after all slave APs finish. When slave AP doesn't hit timeout when executing AP procedure, everything should be good as long as we take good care of the synchronous stuff. But when one slave AP hits timeout, the master AP is treated as hitting timeout as well from BSP's perspective. So BSP resets the two APs (including master AP) which leads to no one restores back the PeiServices pointer. It's true that in such case BSP can do the restore job. But that causes the code very unreadable. >> >>> - or else (possibly the simplest fix), allocate a separate IDT for each >>>    AP, including the UINTN that precedes the (now AP-specific) IDT. This >>>    means that the PEI services pointer*location*  would be separate for >>>    each AP, and no contention would occur. >> I think it's the most complicated fix:) > It might take the most code, but I guess it would be the simplest to > reason about. No data sharing --> no locking necessary, and no races > possible. I will go in this direction. Yes it may introduce more code but much more readable than the above solution. Easy to maintain. > > Anyway, I saw your v2 (just the subject, and your note that we should > ignore v2 for now). I'll stay tuned for v3. > > Meta-question: some of your emails are apparently addressed to the list > only, and not CC'd to people who commented earlier on the thread. Did > you drop CCs deliberately, or is it some kind of mail agent glitch? I am using Outlook for internal communication, ThunderBird for this mailing list. Sometimes I may click [Reply List] button in that mail client. It will only send the mail to the mailing list without CC. I agree [Reply All] is better:) -- Thanks, Ray