From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mx.groups.io with SMTP id smtpd.web10.175565.1673894467280608170 for ; Mon, 16 Jan 2023 10:41:07 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@bsdio.com header.s=fm1 header.b=Jbsp2AAA; spf=pass (domain: bsdio.com, ip: 66.111.4.28, mailfrom: rebecca@bsdio.com) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 95C025C0182; Mon, 16 Jan 2023 13:41:06 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 16 Jan 2023 13:41:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1673894466; x= 1673980866; bh=lCckc83K5cFL3vOljRuuMij4xl9iYIg2FUeWuTrR6+U=; b=J bsp2AAAjsx5QZ6nTzvNhxqmRdfe/0i+DjI0tIW+JngJX+uDiSP4Uz94R8sEITTz4 2bqLb2Jp2XGjgCNruLKR7Q4DKMjtMf6pgYT/ipIay+LN/rdlriLn49w6DqsQDvm8 m/lPGKkRkcRDGcnusEwCDvjhypRmAuFlu88Hu3ylOzG7VZ+NznNFlfUS4aRWnkpA 7Li5JpkjGCYDabgzc4a212S0zaLofzFEgb39RqU0Y5Xt4u6agjJxM/QFyfc/wqb6 lbIvsT5OHpPaVMAVrcGEtc/p2J3Lrr9OLLR0dGhrwYzMxYhGJOvd82PmVFUzXkbQ YVAF2sRnbHhQQLAGPuzBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1673894466; x=1673980866; bh=l Cckc83K5cFL3vOljRuuMij4xl9iYIg2FUeWuTrR6+U=; b=Q7Xo+fyaDoUgD3j3P 7VAjcKhioQyeO4+CVPaTMtcs1dJVkBj9SDpNwV3pGSrcqJAz250qm3nLjoHnhEWY 7PohjJ21D0/j0/Lg3nU/XeVVw5U98GXLEQKrwUA7VcWTuBCsCNleDVk/mUwWVF6U eFfVWkbKA9xZ8TWvErBQr2EgcQMWqNQOWY1RhwYSii+Kj84s0Z+HO05DH4sNA1cd 1uoU5+3feO/EMKAV4OHGdJicicRNj5WzM9C0qprWJMxFENQ8EYj9Mr9dneUDJv3d jrrjLKxtMzznJQhhqr2wmorBr3/22b16gkwXX+sZn9wx9txbGr5If7HLF1X5RGU5 OTD3A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtgedgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeftvggs vggttggrucevrhgrnhcuoehrvggsvggttggrsegsshguihhordgtohhmqeenucggtffrrg htthgvrhhnpeeuheffgeefleeuudefffefjeeiueeggedvfefghfeuteehueehgeeifedt udefheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrvggsvggttggrsegsshguihhordgtohhm X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Jan 2023 13:41:03 -0500 (EST) Message-ID: <4a225b94-909b-a3ef-2487-c4b7edebbf9b@bsdio.com> Date: Mon, 16 Jan 2023 11:41:02 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [edk2-devel] [PATCH v4 2/3] ArmPkg: implement EFI_MP_SERVICES_PROTOCOL based on PSCI calls To: devel@edk2.groups.io, kuqin12@gmail.com, rebecca@quicinc.com, Sami Mujawar , Ard Biesheuvel , Leif Lindholm , Jian J Wang , Liming Gao , Tiger Liu References: <20230104153727.345236-1-rebecca@quicinc.com> <20230104153727.345236-3-rebecca@quicinc.com> From: "Rebecca Cran" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/6/23 15:11, Kun Qin wrote: > On 1/4/2023 7:37 AM, Rebecca Cran wrote: >> +  mCpuMpData.Timeout       = TimeoutInMicroseconds; >> +  mCpuMpData.TimeTaken     = 0; >> +  mCpuMpData.TimeoutActive = (BOOLEAN)(TimeoutInMicroseconds != 0); > > [KQ] Adding a timeout active flag is correct. However, I think each AP > should have its own timeout related > data (that is Timeout, TimeTaken and TimeoutActive). Because i.e. if > this StartupThisAp call is used on AP 1 in > a non-blocking mode, then a subsequent call on AP 2 is blocking, the > common flag and timeout values will > impact both cores, and create unintended timeout events. Good catch! Thanks, I've fixed it by adding per-CPU fields for StartupThisAP. >> +  if (mCpuMpData.TimeoutActive && (mCpuMpData.TimeTaken > >> mCpuMpData.Timeout)) { > [KQ] Similar to the other comment, this is probably better using a > per-core data to track elapsed time. > On a side note, if this timeout ever occurs, this core will never be > usable in next StartupThisAp calls due > to this AP state will not be set to Idle even if the AP procedure is > complete. Is this the intended behavior? No, it wasn't. I've added code to StartupThisAP and StartupAllAPs to accept CpuStateFinished or reset CPUs in that state back to Idle. -- Rebecca Cran