From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.27; helo=mail-in5.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.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 033C220954CBD for ; Tue, 20 Feb 2018 08:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1519143650; x=2383057250; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+VRzuDwaHlHlfR9uG1gEH+NGuJ3KnuzxJStlqUmntVY=; b=hJ9Yf6NUgT61smfPjzah44/+gXRJv+7UazQWLNTkMJWzxUDOCZSs0SuRrXeyiXnm d1ekT8uLCXorLZhMM0gIhnzg6ATEGjaEfQANgqxsFeACLwi3QL5NGa5XjRIGyl9M 2f0EGYUdLhtwsoxjCnzevu+InSNXNqg31hpgpntUWNX/menf/9PEoEH6nTsOuGkW MKsdsxCsS/54fktyTROT/8uQBR76uZTs/FYyMcheAmZLpJnvO/xW8/xj7pdF0P8Q qPa5dvPHIXJ7R2zVicP9yMaVc7+Iu0Zgoc6SaLIAaJvwB148i/UFyRspn8cdH3wk W5i/dd+wGDoKoVJgJwrSkA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 1B.A1.13704.1EA4C8A5; Tue, 20 Feb 2018 08:20:50 -0800 (PST) X-AuditID: 11973e13-3f68e9e000003588-d1-5a8c4ae17538 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id 8B.E9.26650.1EA4C8A5; Tue, 20 Feb 2018 08:20:49 -0800 (PST) MIME-version: 1.0 Received: from [17.234.1.171] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P4G00M7BIQPCR20@nwk-mmpp-sz12.apple.com>; Tue, 20 Feb 2018 08:20:49 -0800 (PST) Sender: afish@apple.com From: Andrew Fish In-reply-to: <20180220141641.p47czk4yb74xutyu@bivouac.eciton.net> Date: Tue, 20 Feb 2018 08:20:48 -0800 Cc: Ard Biesheuvel , ruiyu.ni@intel.com, edk2-devel@lists.01.org, liming.gao@intel.com, Mike Kinney , lersek@redhat.com, star.zeng@intel.com Message-id: References: <20180220110524.9050-1-ard.biesheuvel@linaro.org> <20180220110524.9050-2-ard.biesheuvel@linaro.org> <20180220141641.p47czk4yb74xutyu@bivouac.eciton.net> To: Leif Lindholm X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUi2FDorPvIqyfK4IO9xf8Puxkt9hw6ymzx afceFotlx3awWKy4t4HdoqPjH5PFy57V7Bb7eq0dODwW73nJ5HHn2h42j+7Z/1g83u+7yhbA EsVlk5Kak1mWWqRvl8CVcevWf7aCf/IVF25+Ym1gfC7RxcjJISFgIvFv4TqmLkYuDiGB1UwS y25eZ4VJvJzdwQiROMQocfT+WnaQBK+AoMSPyfdYuhg5OJgF5CUOnpcFCTMLaEl8f9TKAlH/ hVGie/ViFpCEsIC4xLszm5ghbD+JI2+2sIHYbALKEivmfwCbySngKNG/+SHYYhYBVYmPj3aw gQxiFjjJKPHizjxWkGW8AjYSV3cmQixYwSix+ssEsKEiAjoSp7/+Y4a4Wkli+vfbYM0SAkfY JHbt+8U4gVF4FpLDZyEcPgvJ4QsYmVcxCuUmZuboZuaZ6iUWFOSk6iXn525iBEXKdDvhHYyn V1kdYhTgYFTi4bXQ6YkSYk0sK67MPcQozcGiJM6rl9odJSSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFRy8p7Ro/0rncbHAtlFkoYFxf9/nzhdun6goCXTO0lvj2liyOWfcmYeygkVW9iYuxE h3NJxpfnbV5/tCMjaPONyCty8z5dEKw5ElumNV3XJ+qs/nWdRlPl7HdSknJBV35Ec6a+Z3E9 pGFhJN3D8OnCzo0TX8w+yS+xTjjx2RVF8Z1+RdWPJGOVWIozEg21mIuKEwHJ9ooTdQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FB8RvehV0+UQfd1K4v/H3YzWuw5dJTZ 4tPuPSwWy47tYLFYcW8Du0VHxz8mi5c9q9kt9vVaO3B4LN7zksnjzrU9bB7ds/+xeLzfd5Ut gCWKyyYlNSezLLVI3y6BK+PWrf9sBf/kKy7c/MTawPhcoouRk0NCwETi5ewOxi5GLg4hgUOM Ekfvr2UHSfAKCEr8mHyPpYuRg4NZQF7i4HlZkDCzgJbE90etLBD1XxglulcvZgFJCAuIS7w7 s4kZwvaTOPJmCxuIzSagLLFi/gewmZwCjhL9mx+ygtgsAqoSHx/tYAMZxCxwklHixZ15rCDL eAVsJK7uTIRYsIJRYvWXCWBDRQR0JE5//ccMcbWSxPTvt9kmMArMQnLrLIRbZyG5dQEj8ypG gaLUnMRKI73EgoKcVL3k/NxNjODQLnTewXhsmdUhRgEORiUe3gl6PVFCrIllxZW5wMDgYFYS 4b38vTtKiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JKaCUQHpiSWp2ampBahFMlomDU6qBcV7X v1Nf2P6qJovPVr6V/99Wf63Ybrddajwe2YvOr3abllUybU1uy/brhw44HO96ufh72X7WF9w1 ncuX+HnvvfMgptct5bP0lBlbLkobJBbGT5vYEDcvhkHNIWrGdJfOg9rRG7mW6S5VXO9UdfeL 8V+n56s0+crvLVW+eF15YttXob/qkxcksSqxFGckGmoxFxUnAgDPDiqGaQIAAA== Subject: Re: [PATCH 1/3] MdePkg: introduce DxeRuntimeDebugLibSerialPort X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 16:14:53 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Feb 20, 2018, at 6:16 AM, Leif Lindholm wrote: > > On Tue, Feb 20, 2018 at 11:05:22AM +0000, Ard Biesheuvel wrote: >> +/** >> + Prints an assert message containing a filename, line number, and description. >> + This may be followed by a breakpoint or a dead loop. >> + >> + Print a message of the form "ASSERT (): \n" >> + to the debug output device. If DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED bit >> + of PcdDebugProperyMask is set then CpuBreakpoint() is called. Otherwise, if >> + DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED bit of PcdDebugProperyMask is set then >> + CpuDeadLoop() is called. If neither of these bits are set, then this function >> + returns immediately after the message is printed to the debug output device. >> + DebugAssert() must actively prevent recursion. If DebugAssert() is called >> + while processing another DebugAssert(), then DebugAssert() must return >> + immediately. >> + >> + If FileName is NULL, then a string of "(NULL) Filename" is printed. >> + If Description is NULL, then a string of "(NULL) Description" is >> + printed. >> + >> + @param FileName The pointer to the name of the source file that generated >> + the assert condition. >> + @param LineNumber The line number in the source file that generated the >> + assert condition >> + @param Description The pointer to the description of the assert condition. >> + >> +**/ >> +VOID >> +EFIAPI >> +DebugAssert ( >> + IN CONST CHAR8 *FileName, >> + IN UINTN LineNumber, >> + IN CONST CHAR8 *Description >> + ) >> +{ >> + CHAR8 Buffer[MAX_DEBUG_MESSAGE_LENGTH]; >> + >> + if (!mEfiAtRuntime) { >> + // >> + // Generate the ASSERT() message in Ascii format >> + // >> + AsciiSPrint (Buffer, sizeof (Buffer), "ASSERT [%a] %a(%d): %a\n", >> + gEfiCallerBaseName, FileName, LineNumber, Description); >> + >> + // >> + // Send the print string to the Console Output device >> + // >> + SerialPortWrite ((UINT8 *)Buffer, AsciiStrLen (Buffer)); >> + } >> + >> + // >> + // Generate a Breakpoint, DeadLoop, or NOP based on PCD settings >> + // >> + if ((FixedPcdGet8 (PcdDebugPropertyMask) & >> + DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED) != 0) { >> + CpuBreakpoint (); >> + } else if ((FixedPcdGet8 (PcdDebugPropertyMask) & >> + DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED) != 0) { >> + CpuDeadLoop (); >> + } > > Hmm ... I know this does not fundamentally change the behaviour of the > existing implementation, but if we're looking to improve runtime > behaviour, we've just gone from generating a runtime fault to silently > freezing (if BREAKPOINT_ENABLED or DEADLOOP_ENABLED). > > What do breakpoint/deadloop mean in a runtime context anyway - do we > not need to halt _all_ running cores? > > I don't see an obvious "right way" solution here, and this only > affects DEBUG builds. Leif, It is not related to DEBUG builds, it is related to PCD configuration. > Possible ways of handling this that I can think > of include: > - Don't respect BREAKPOINT/DEADLOOP if at runtime. > - Respect BREAKPOINT/DEADLOOP and disable all cores. > - Take ownership back of the system and re-enable 1:1 mapping so > messages can be printed. > There is not much risk of losing user data if you "panic" EFI, that is not true if you are going to "panic" the OS. I've seen more bugs at runtime from confusion about what is legal to do at runtime, vs. actual bugs. You can always just return device error on failure, and if the RT Services hangs you can core dump the OS. Given the OS provided the virtual mapping it is likely the stuck EFI could would be in the stack trace of the panic. Thanks, Andrew Fish > / > Leif > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel