From: "Johnson, Michael" <michael.johnson@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] [Patch 0/2] UefiCpuPkg: Default avoid print.
Date: Wed, 31 Jul 2019 15:04:39 -0700 [thread overview]
Message-ID: <4873.1564610679757881540@groups.io> (raw)
In-Reply-To: <93d4a7e7-9b86-b3c9-a476-ac1a40dc4723@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]
On Wed, Jul 31, 2019 at 11:58 AM, Laszlo Ersek wrote:
>
> I'm sure I'm misremembering parts of this story (from several years
> distance), the moral is that debugging in a multiprocessing environment
> may easily require its own dedicated infrastructure. In edk2, we don't
> have anything like that, I think. Could we build it, sufficiently
> generally? Like, prepare a log buffer for each CPU before calling
> StartupAllAps(), log only to that buffer during the concurrent
> execution, and finally dump the buffers? I guess if we don't *reach* the
> "finally" part, we could still dump the RAM and investigate the log
> buffers that way... Dumping the RAM is certainly an option for virtual
> machines, but it might be viable for physical setups too (JTAG, debug
> agent... dunno).
>
> Sorry about the wild speculation :)
Laszlo,
The wild speculation is good. In fact, I would say it should get wilder still. Consider systems with multiple CPU sockets contending for control of a single debug channel. There is no edk2 solution for granting and revoking control of debug between sockets. Worse still, early enough in boot there may be no coherent memory where the sockets could put log buffers, so we can't charge one of them with dumping all the output. Instead it becomes necessary to solve the coordination problem more directly.
I actually have this problem, and a functional-but-not-pretty solution. I'd like to see an edk2 supported way to handle it. What I've got now funnels all such debug through the report status code infrastructure and replaces the serial port status code handler with an implementation that's gated by a hardware-backed coordination primitive. I don't see a way around putting a hardware-backed primitive in there somewhere if sockets without shared memory are to be supported, but the rest of the details are open to alternatives.
A solution would need to define one-or-more coordination primitives via library class and create some way to enable those libraries to gate debug. This can work for sockets or APs at any time, while buffer-and-dump can only work on sockets if they've already got coherent memory. Of course buffer-and-dump has other desirable properties and doesn't require anything from hardware, so maybe we want to enable both things at the levels they work/make sense.
While I'm blathering about debug, I do not see a downside to making MAX_DEBUG_MESSAGE_LENGTH a fixed at build PCD. It's currently #define'd in a variety of places, which in my opinion is just asking for trouble.
Does anybody have any other cans of worms to open on the broadening-debug-infrastructure front?
Thanks,
-Michael
[-- Attachment #2: Type: text/html, Size: 3163 bytes --]
next prev parent reply other threads:[~2019-07-31 22:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 7:35 [Patch 0/2] UefiCpuPkg: Default avoid print Dong, Eric
2019-07-31 7:35 ` [Patch 1/2] UefiCpuPkg/RegisterCpuFeaturesLib: " Dong, Eric
2019-07-31 7:35 ` [Patch 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: " Dong, Eric
2019-07-31 12:43 ` [Patch 0/2] UefiCpuPkg: " Laszlo Ersek
2019-07-31 16:34 ` [edk2-devel] " Brian J. Johnson
2019-07-31 18:06 ` Andrew Fish
2019-07-31 18:58 ` Laszlo Ersek
2019-07-31 22:04 ` Johnson, Michael [this message]
2019-08-02 0:12 ` Laszlo Ersek
2019-08-01 20:20 ` Brian J. Johnson
2019-08-01 21:14 ` Andrew Fish
2019-08-02 21:45 ` Laszlo Ersek
2019-08-01 7:51 ` Ni, Ray
2019-08-01 9:07 ` Dong, Eric
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=4873.1564610679757881540@groups.io \
--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