From: "Andrew Fish via groups.io" <afish=apple.com@groups.io>
To: edk2-devel-groups-io <devel@edk2.groups.io>,
Andrew Fish <afish@apple.com>
Cc: fanjianfeng@byosoft.com.cn, yoshinoyatoko <yoshinoyatoko@163.com>
Subject: Re: [edk2-devel] Is DEBUG output function safe for MP case?
Date: Fri, 31 May 2024 05:14:34 -0500 [thread overview]
Message-ID: <4B16E760-53C0-4CF1-852F-16DD8DAA965D@apple.com> (raw)
In-Reply-To: <17D48A6E78A3E42F.21428@groups.io>
[-- Attachment #1: Type: text/plain, Size: 4688 bytes --]
There is also one extra caveat about UEFI runtime that I forgot to mention. There is no way to share the hardware between UEFI and the OS, so UEFI really needs dedicated hardware.
Thanks,
Andrew Fish
PS This makes me think of a Windows story from the 1990’s when Windows added Plug-and-Play for serial to detect modems. A factory updated Windows on a PC that controlled a CnC machine and the modem auto detect AT commands got sent to the CnC machine, and this told the CnC machine to start drilling holes in the CnC machine.
> On May 31, 2024, at 4:59 AM, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>
> I think the generic answer is no DEBUG() is not guaranteed to be MP safe.
>
> Jeff is pointing out in the edk2 your platform build can control what libraries are used to implement DEBUG(), so you might be able to make it work in your case.
>
> Base libs are libraries that don’t depend on other things so they have a much better chance of working but they will have at least 2 issue:
> 1) The are not MP safe so the output could get intermixed and things could get lost as multiple agents try to to write to the UART in parallel
> 2) A Base lib that goes after a x86 IO port has a chance of working at runtime, but an ARM UART driver that uses an MMIO address is not going to work as the that MMIO range would need a virtual mapping and a Base lib is not going to request that.
>
> You can search for instances of the DebugLib (that implements DEBUG) by grepping the inf files.
>
> /Volumes/Case/edk2(master)>git grep DebugLib -- \*.inf | grep LIBRARY_CLASS | grep DXE_RUNTIME_DRIVER
> ArmPkg/Library/SemiHostingDebugLib/SemiHostingDebugLib.inf:19: LIBRARY_CLASS = DebugLib|BASE SEC DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER
> ArmVirtPkg/Library/DebugLibFdtPL011Uart/DxeRuntimeDebugLibFdtPL011Uart.inf:23: LIBRARY_CLASS = DebugLib|DXE_RUNTIME_DRIVER
> MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf:19: LIBRARY_CLASS = DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE PEIM SEC PEI_CORE UEFI_APPLICATION UEFI_DRIVER MM_STANDALONE
> MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf:22: LIBRARY_CLASS = DebugLib|DXE_RUNTIME_DRIVER
> MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf:22: LIBRARY_CLASS = DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
> MdePkg/Library/UefiDebugLibDebugPortProtocol/UefiDebugLibDebugPortProtocol.inf:22: LIBRARY_CLASS = DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
> MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf:22: LIBRARY_CLASS = DebugLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
> OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf:19: LIBRARY_CLASS = DebugLib|PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER UEFI_APPLICATION
>
> Note: DXE_RUNTIME_DRIVE may not imply the the DEBUG works at running, and it may only support DEBUG print a Boot Services time. But if you look at the list you will see some of the libs are designed to used at runtime. So that should imply they deal with virtual address mapping and locks.
>
> Thanks,
>
> Andrew Fish
>
>> On May 31, 2024, at 1:33 AM, Jeff Fan via groups.io <fanjianfeng=byosoft.com.cn@groups.io> wrote:
>>
>> AP cannot run any UEFI Service. Please make sure AP code use base-typed DebugLib instance (Such as BaseDebugLibSerialport.inf from MdePkg)
>>
>>
>> fanjianfeng@byosoft.com.cn <mailto:fanjianfeng@byosoft.com.cn>
>>
>> 发件人: Yoshinoya <mailto:yoshinoyatoko@163.com>
>> 发送时间: 2024-05-31 14:22
>> 收件人: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>> 主题: [edk2-devel] Is DEBUG output function safe for MP case?
>> Hello
>> I ask for help for debug output in multi-core case.
>>
>> Is the current DEBUG marco safe for AP Cores to output message?
>> If the output message is too long, it takes too much time, will it cause some abnormal exception?
>>
>> Thanks
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119410): https://edk2.groups.io/g/devel/message/119410
Mute This Topic: https://groups.io/mt/106405152/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
[-- Attachment #2: Type: text/html, Size: 18419 bytes --]
next prev parent reply other threads:[~2024-05-31 10:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 6:22 [edk2-devel] Is DEBUG output function safe for MP case? Yoshinoya
2024-05-31 6:33 ` 回复: " Jeff Fan via groups.io
2024-05-31 9:59 ` Andrew Fish via groups.io
[not found] ` <17D48A6E78A3E42F.21428@groups.io>
2024-05-31 10:14 ` Andrew Fish via groups.io [this message]
2024-06-03 8:24 ` 回复: " Yoshinoya
2024-06-04 1:11 ` 回复: " Jeff Fan via groups.io
2024-06-06 4:57 ` Yoshinoya
[not found] ` <17D65170E6B4AF25.31248@groups.io>
2024-06-12 4:42 ` [edk2-devel] processing compressed section during CAR phase Yoshinoya
2024-06-20 8:56 ` [edk2-devel] uncompress peims during car phase Yoshinoya
2024-06-06 4:55 ` [edk2-devel] pci command supports CXL device type Yoshinoya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B16E760-53C0-4CF1-852F-16DD8DAA965D@apple.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox