From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (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 C4415211799C0 for ; Thu, 14 Jun 2018 08:00:49 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 145E9818BAFD; Thu, 14 Jun 2018 15:00:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-139.rdu2.redhat.com [10.10.120.139]) by smtp.corp.redhat.com (Postfix) with ESMTP id 689CA2166BB2; Thu, 14 Jun 2018 15:00:47 +0000 (UTC) To: Andrew Fish , "Duran, Leo" Cc: "edk2-devel@lists.01.org" , "Singh, Brijesh" , Jordan Justen , Liming Gao , Paolo Bonzini , Jeff Fan References: <1528920674-24912-1-git-send-email-leo.duran@amd.com> <1528920674-24912-2-git-send-email-leo.duran@amd.com> <9e2b3f74-c37e-06d9-293e-04976713ce8c@redhat.com> From: Laszlo Ersek Message-ID: <69709be6-0469-1f82-7a5e-48a93a3520c2@redhat.com> Date: Thu, 14 Jun 2018 17:00:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 14 Jun 2018 15:00:49 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 14 Jun 2018 15:00:49 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH] UefiCpuPkg/LocalApicLib: Exclude second SendIpi sequence on AMD processors. 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: Thu, 14 Jun 2018 15:00:51 -0000 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/14/18 16:52, Andrew Fish wrote: > > >> On Jun 14, 2018, at 7:08 AM, Duran, Leo wrote: >> >> >> >>> -----Original Message----- >>> From: Laszlo Ersek > >>> Sent: Wednesday, June 13, 2018 3:50 PM >>> To: Duran, Leo >; edk2-devel@lists.01.org >>> Cc: Jordan Justen >; Jeff Fan >>> >; Liming Gao >; Singh, Brijesh >>> >; Paolo Bonzini >; Igor >>> Mammedov > >>> Subject: Re: [edk2] [PATCH] UefiCpuPkg/LocalApicLib: Exclude second >>> SendIpi sequence on AMD processors. >>> >>> Hello Leo, >>> >>> On 06/13/18 22:11, Leo Duran wrote: >>>> On AMD processors the second SendIpi in the SendInitSipiSipi and >>>> SendInitSipiSipiAllExcludingSelf routines is not required, and may >>>> cause undesired side-effects during MP initialization. >>>> >>>> This patch leverages the StandardSignatureIsAuthenticAMD check to >>>> exclude the second SendIpi and its associated MicroSecondDelay (200). >>> >>> QEMU and KVM emulate some AMD processors too; of particular interest is >>> the recent EPYC addition, I believe (for SME/SEV, minimally). >>> >>> Did you check whether the StandardSignatureIsAuthenticAMD() check >>> applies to those QEMU VCPU models, and if so, whether omitting the second >>> Startup IPI interferes with *V*CPU startup in OVMF guests? (In >>> multiprocessing modules, such as CpuMpPei, CpuDxe, and >>> PiSmmCpuDxeSmm.) >>> >>> Adding Brijesh, Paolo and Igor. >>> >>> Thanks! >>> Laszlo >> >> Hi Lazlo, >> >> My understanding is that hypervisors simply ignore the second SIPI, so a single (or double) SIPI should be fine. >> In any event, I'm checking with Brijesh on your specific question. >> > > My understanding is the 2nd SIPI was for an Intel processor bug in the mid 1990's and it has not been required since. People are just scared to change it since all the Operating Systems have been historically validated against INT SIPI SIPI. > > One of my co-works removed our extra SIPI, not knowing the history, and everything worked. Well we booted a little faster without the extra SIPI. > > If people still have the compatibility concern can we make the 2nd SIPI configurable via a PCD. But given the StandardSignatureIsAuthenticAMD() data point we should default the 2nd SIPI to off and move the world forward? What do folks think? Given that I asked Brijesh to comment too, I'd like to see his feedback as well (or Leo to forward Brijesh's findings); then I'm OK with removing the second SIPI. Thanks Laszlo