From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [Patch 0/2] UefiCpuPkg: Default avoid print. To: Laszlo Ersek ,devel@edk2.groups.io From: "Johnson, Michael" X-Originating-Location: Vancouver, Washington, US (134.134.139.75) X-Originating-Platform: Windows Chrome 75 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Wed, 31 Jul 2019 15:04:39 -0700 References: <93d4a7e7-9b86-b3c9-a476-ac1a40dc4723@redhat.com> In-Reply-To: <93d4a7e7-9b86-b3c9-a476-ac1a40dc4723@redhat.com> Message-ID: <4873.1564610679757881540@groups.io> Content-Type: multipart/alternative; boundary="vXnu3opgn2zHMVzsJAbK" --vXnu3opgn2zHMVzsJAbK Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2019 at 11:58 AM, Laszlo Ersek wrote: >=20 > 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). >=20 > Sorry about the wild speculation :) Laszlo, The wild speculation is good.=C2=A0 In fact, I would say it should get wil= der still.=C2=A0 Consider systems with multiple CPU sockets contending for = control of a single debug channel.=C2=A0 There is no edk2 solution for gran= ting and revoking control of debug between sockets.=C2=A0 Worse still, earl= y enough in boot there may be no coherent memory where the sockets could pu= t log buffers, so we can't charge one of them with dumping all the output.= =C2=A0 Instead it becomes necessary to solve the coordination problem more= directly. I actually have this problem, and a functional-but-not-pretty solution.=C2= = =A0 I'd like to see an edk2 supported way to handle it.=C2=A0 What I've go= t now funnels all such debug through the report status code infrastructure = and replaces the serial port status code handler with an implementation tha= t's gated by a hardware-backed coordination primitive.=C2=A0 I don't see a = way around putting a hardware-backed primitive in there somewhere if socket= s without shared memory are to be supported, but the rest of the details ar= e open to alternatives. A solution would need to define one-or-more coordination primitives via li= brary class and create some way to enable those libraries to gate debug.=C2= = =A0 This can work for sockets or APs at any time, while buffer-and-dump ca= n only work on sockets if they've already got coherent memory.=C2=A0 Of cou= rse buffer-and-dump has other desirable properties and doesn't require anyt= hing from hardware, so maybe we want to enable both things at the levels th= ey work/make sense. While I'm blathering about debug, I do not see a downside to making MAX_DE= BUG_MESSAGE_LENGTH a fixed at build PCD.=C2=A0 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 --vXnu3opgn2zHMVzsJAbK Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 envi= ronment
may easily require its own dedicated infrastructure. In edk2, = we don't
have anything like that, I think. Could we build it, sufficie= ntly
generally? Like, prepare a log buffer for each CPU before calling=
StartupAllAps(), log only to that buffer during the concurrent
e= xecution, 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 sa= y it should get wilder still.  Consider systems with multiple CPU sock= ets contending for control of a single debug channel.  There is no edk= 2 solution for granting and revoking control of debug between sockets. = ; Worse still, early enough in boot there may be no coherent memory where t= he sockets could put log buffers, so we can't charge one of them with dumpi= ng all the output.  Instead it becomes necessary to solve the coordina= tion 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 t= he report status code infrastructure and replaces the serial port status co= de handler with an implementation that's gated by a hardware-backed coordin= ation primitive.  I don't see a way around putting a hardware-backed p= rimitive in there somewhere if sockets without shared memory are to be supp= orted, but the rest of the details are open to alternatives.

A s= olution would need to define one-or-more coordination primitives via librar= y 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 onl= y work on sockets if they've already got coherent memory.  Of course b= uffer-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 wo= rk/make sense.

While I'm blathering about debug, I do not see a = downside to making MAX_DEBUG_MESSAGE_LENGTH a fixed a= t build PCD.  It's currently #define'd in a variety of places, which i= n my opinion is just asking for trouble.

Does anybody have any o= ther cans of worms to open on the broadening-debug-infrastructure front?
Thanks,
-Michael --vXnu3opgn2zHMVzsJAbK--