From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id D5397D807AB for ; Thu, 25 Jan 2024 14:25:43 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=qweAsPiGLlxzWxKAqPctxXYWHdyD9w1CLF/bg7c2AdE=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:To:References:From:Autocrypt:In-Reply-To:Feedback-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1706192742; v=1; b=cxtr/EjMXFGUXSldd6KA71McuQ1zAdtrA80UWUPXKGLUAcrk6kzOfYnZrlrq0FcU6U9Uar0g V1yXg9X9f1TviNLEUqIy7OxbfLdpxcNK74gMNn1bjBCft5cFpdP3lEieW+o7C5nsmAqB53Lnqsb wfXBcr22LwfyjOXDXFEWUlxo= X-Received: by 127.0.0.2 with SMTP id r1xNYY7687511xMzHhpprEmL; Thu, 25 Jan 2024 06:25:42 -0800 X-Received: from a7-19.smtp-out.eu-west-1.amazonses.com (a7-19.smtp-out.eu-west-1.amazonses.com [54.240.7.19]) by mx.groups.io with SMTP id smtpd.web11.18855.1706192741286623541 for ; Thu, 25 Jan 2024 06:25:41 -0800 Message-ID: <0102018d41031cb5-c2701b16-0698-4004-9217-2204050254f7-000000@eu-west-1.amazonses.com> Date: Thu, 25 Jan 2024 14:25:39 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] RFC: Another solution to the nested interrupt issue To: devel@edk2.groups.io, ray.ni@intel.com, Laszlo Ersek , "Kinney, Michael D" References: <0102018d40b796c3-4a61aa4c-dc30-444d-b731-470396d46072-000000@eu-west-1.amazonses.com> From: "Michael Brown" Autocrypt: addr=mcb30@ipxe.org; keydata= xsFNBGPmfF4BEAC3vcU4aLC/9Uy/rTpmYujbqxQNZje9E34jGvLxO3uYwj4BeHj1Nn5T2TDM Gkc4ngk+mGPsJsIn69YU5cfVN+ch9O7FVfsn6egZsCNeLy6Qz0o//gBaWJodFBeawuBjXXyV HnQZa1p7bA/Lws8minW7NrZ7XZgEBaiVm1v1dNbLEoWR8UL2AMtph5loCQ5jPYQNqp/wH9El /R30GjXvAd1riWyJR2TWSN23J9rnuH2Ue+N4yEnWxAsBQ6M/NFQ5z42w4mYdsnzy1w3PulrL icpSixXHkm3lQcKGtKKX41HvJukSpxCgbHfuHGEJZ7bdhgRic1DHKav0JR8kQhx3gnPh06z8 1Teu2NKkSsTR3Iv6E2x6Yy6H34lKWzBzd8TLNSevesDD/L6NU/HxT9AxrTBuypk9PZGe2VH1 W03XnR/0Mnr0QqQBXcIAERdgNzRJY4VKF75vedf8IooZFUQ4RUlqH+x3aZB9nJ9ET77mPaNi SQVQBxE68uzb7eh2Kf6z7ftOYpWPw1v5HyB3oMmafEDG36SIvNF2wnmNaLQDRnAbTcy4ERgy tpJ3wtQDJeXOePLv8hJ3q7DSuePl7cwz4xy0ZHglW/EXRXLnyRRACfDGowyENoStg06qF+qm edGu1wNtmDZ/lypWm/CkzzpUDFeGP5BLZlqwVX4hn88llfvVzwARAQABzR5NaWNoYWVsIEJy b3duIDxtY2IzMEBpcHhlLm9yZz7CwZEEEwEIADsWIQTgD69MBpjBm2slMvwCNbEKAOtEUAUC Y+Z8nwIbAwULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRACNbEKAOtEUFlhD/9ElIUg JxBXpIbF8s7u79OdXLld2Z1DfVmhP5Q+GilPvEeAWHhp689S9B88aNvpwW5zJfxlxcJZO0ay jc7E/vtdNrkXGWNEEXBgdve6m+uL+pW/i5E2htqxbLyfgTJKmsvJ8graHbwrrBS/PA8KuwVJ eAGbBNi3f1gyQQWrLqfTkUpLtuj7A76iVVk0G0a78L69Al84qhK2imqpFJoZt1F8h0Z5ddGv mvf2M/DZp87UXvXjy7X6r7msbMZa6S/Jv0dtWHeZGl3Xu3qzbtjlqFyz2Q7TibHiirsgg/CV BsbH/LLbi/aNCCQ/85C6jAMB0lNzcVZ7ZiKKo+vBNMTycDFk70LA9yjlNf7exHejoXmPkLmH ddapYZ4dzwdOiJlaTu8NZgzXUCt3RDDA1qmZrAOBF/F+tPILAEhenl9kj3blD3mPV2SrWLWY dbahY9BsylUhj/qE1ik5CJXrPotmJhok9Vpg07xKDpVnZXuWLGNIE8018UumO7phLrWQwLb1 wJdN7PG165w4UWf4aQphfwaMKOVU3WDghz3aVSP9rgtm3RsUcYHPKx8IaPcDh2yf0bgG386i Axx3U3UQeyz2Pb9Vigo6DmPwXjLkFr/dukvVLVJLVkUab9ZhhERzWTEEMifUVEK2rGNvA87L VKJ2zOyxWx1e0CPj6fcGbkJ0D10XLs7BTQRj5nxeARAAz18zv2ksRiM6eEKG0qzpiKHVYlVy wtjla+m9wuAIwm314tffY5hjQN46uwTstdhQirjywF1EmcS6KNGiIjmoLim+dqyFP5d/UF5A VjLt0TYq7HjadIxbm2/CvcRnNJ01FkD99xLxV0hFTUAWAUX1mNqQ3MmWIjV89wiT06uuAUog m+jG3RRDyWbUnVELR60mhzccKsaEsjO/HqIERvBwL7tlOJewlPrVyz9Zed9Nhhv0KDAYmdEm kIEEbOfsjRu5I6nIY3NrX+QP9+nmgxADlsjvLXTSU0fT/g7IPEl3gpsQZAbgmrlGcPtvXod8 P4iOmL8GJDU1RdBE9TBOLEbu9UlDRD4zr6tdzRpB9wvXdtSUcNCdHVqJTfq2qjIlBk7x+zQD ayhxzDvTMxD/93K6txKXmVVtfMBsmt9KuD2JBUEAExjsLHqzg48nQg8wF9JYWCWGBb36qpd0 yC6VPzhSLe2Ov3/GyV5ZshO046+OiGxEeaHCwMnDTZF9xrQ5paCwWedlWKvGM2zB64AHuk+M v2ABK/gbDO7eS6p+xz11oD1NHr1HQLRtknfClIqj9AmjgX9maD+4GUrmHaxmkNilIukahotd Un9Up2gX05Wy/S3H/v8RB0kxwWg2Wh065dnyCF4Doe18bcYZvM+iMJmUBag6aDfQlryM04K7 z4ITYDkAEQEAAcLBdgQYAQgAIBYhBOAPr0wGmMGbayUy/AI1sQoA60RQBQJj5nxeAhsMAAoJ EAI1sQoA60RQZj4QAIkiRDVNWynZ4kEdpqmf6hpD++Zycz+LMne4iGRsiyyTf/rPNgskNLrU JD555yDvFiEAhOI27R8YNCJj5byXRDa/Bm6ueClFia+POibt28UEdyOFU9PVcgFaU+VxaBIP rHacHL6A7UKFjmBN7o8VkVF2xXlmFge795mP4/Y3t6qfWUTodrpw1w1t5/bZxZdWqX4pUCpY fEx87jm60+Mj0Tb4VPWXz0UD1q1BDcdYxNa2ISLaJhGJmjjks9eqdFOhPo1fTINMNWF2Alxi jA6WNT8nn9lm1kav75EMYMc8WIR9tb03i+IuKNp2IWwTGBqIUyQj00BhHkZQFl4HxZhV0gXE AWu34Q/Z7hOUXGXq2tvYCxDeaQb2wks93e62lrrUm1JGhPWkVoCI8Md8N2mkonqIfMK8lQ0W WbkYHdKBkgDqhDypNNhkjWNX3JL1kL0c3rqGL381iBAZaGQPygyCx2xH9PDNp59W6u8sXb13 +UX+kXdWU+KYbMTVoO/t4MxUJg6nXPJHz9NCkyluI820l+2OtXZZy0u196evIlUdD6RoTrNK z5OgFxNctVi9BPsQea9du+JlYJ460vZNPz180oczj7iqffd+p9DmAkeK25njWhg3qPeXiNZN 45J9eMChSOaJ0GMGUQndIIxz7PO8IzjbkSHLG5CKrR3MaphMB/0L In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Feedback-ID: 1.eu-west-1.fspj4M/5bzJ9NLRzJP0PaxRwxrpZqiDQJ1IF94CF2TA=:AmazonSES X-SES-Outgoing: 2024.01.25-54.240.7.19 Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,mcb30@ipxe.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: RF8VydWCxNb9ywYmvUfc0EB1x7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b="cxtr/EjM"; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=none On 25/01/2024 13:54, Ni, Ray wrote: >> I don't disagree with the approach, but it does break the API as per the >> UEFI PI specification (version 1.8 section II-12.10), and so this is not >> something that can just be dropped in as an EDK2 code change. >=20 > You think that the TimerInterruptHandler() doesn't raise/restore TPL > which would violate the PI spec as PI spec says " NotifyFunction ... exec= utes at EFI_TPL_HIGH_LEVEL."? >=20 > I do not think the PI spec requires TimerInterruptHandler() raises TPL > to HIGH before invoking NotifyFunction. It just means the NotifyFunction > will execute at TPL_HIGH. If the caller is not supposed to raise TPL to TPL_HIGH_LEVEL before=20 calling NotifyFunction, then the statement "This function executes at=20 EFI_TPL_HIGH_LEVEL" in the PI specification is meaningless. There is no=20 other possible interpretation besides "the caller must raise TPL to=20 TPL_HIGH_LEVEL before calling this function". > If you review HpetTimer driver, it does not raise TPL to HIGH before > invoking NotifyFunction. That would then be a bug in HpetTimer, which ought to be fixed. If=20 HpetTimer were to be used on a platform where the NotifyFunction=20 correctly assumes that it is called at TPL_HIGH_LEVEL and does something=20 that would break at a lower level, then this could lead to undefined=20 behaviour. > And I think implementing the DxeCore changes as attached does not > prevent the TimerInterruptHandler() from calling raise/restore TPL. No, but a spec-conforming timer interrupt handler could not take=20 advantage of the feature, because it would have to raise to=20 TPL_HIGH_LEVEL before calling the NotifyFunction. (Any raise/restore=20 within the NotifyFunction would then have no effect.) > So, with the changes done in DxeCore, a timer driver could either > not raise/restore TPL in TimerInterruptHandler(), or it calls > NestedInterruptTplLib if it wants. As a pure code change, I do agree that it solves the problem and it's a=20 much simpler approach. However, it is a breaking change to the=20 specification and I think it would need be handled as such. The minimal specification change I can think of that would make this=20 possible would be to relax the wording on NotifyFunction in the next=20 version of the PI specification to say that * the NotifyFunction can be called at any TPL level * the NotifyFunction will raise TPL to TPL_HIGH_LEVEL, restore TPL back=20 to the original TPL before returning * the NotifyFunction may re-enable interrupts during its execution, and=20 that the caller must be prepared to be re-entered before NotifyFunction=20 returns * the timer interrupt must have been rearmed before calling NotifyFunction * the NotifyFunction must guarantee that it never reaches a state in=20 which the TPL has been restored to the original level with CPU=20 interrupts enabled. This would be backwards compatible with the existing behaviour. A=20 caller written to the current specification would call NotifyFunction at=20 TPL_HIGH_LEVEL and so any RaiseTPL/RestoreTPL done within a=20 NotifyFunction complying to the new specification would be a no-op anyway. A caller written to the new specification would have to check the=20 supported version of the PI specification (which I assume is available=20 in some system configuration table somewhere) to know that it was safe=20 to call NotifyFunction without first raising to TPL_HIGH_LEVEL. This approach would at least avoid the need for an ARCH2_PROTOCOL=20 variant, which is potentially lower impact. Thanks, Michael -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114407): https://edk2.groups.io/g/devel/message/114407 Mute This Topic: https://groups.io/mt/103950154/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-