Re: Runtime configuration methods for OVMF/AAVMF?

Laszlo Ersek

On 03/12/21 18:11, Laszlo Ersek wrote:
On 03/11/21 19:13, Aaron Young wrote:

DebugLogMask 0x8040004F

First, there are multiple PCDs related to debug messages.

Second, those PCDs cannot be made dynamic-access; the DEBUG macro is
used in SEC modules too, and SEC does not have dynamic PCD access
(dynamic PCDs are implemented in the PEI phase via the PCD PPI, and in
the DXE phase via the PCD protocol).

Furthermore, if memory serves, the DXE Core can also not use dynamic
PCDs (precisely because the PEI phase is gone, but the DXE protocol is
not available yet), but at the same time, the DXE Core produces quite
relevant log messages.

So only Fixed-At-Build access is appropriate for these PCDs.
("Patchable" would be an option only if we didn't use LZMA compression
inside the firmware image, I think -- in that case, PCDs in the firmware
binary could be tweaked with external tools.)

Third, in a platform DSC file, Fixed-At-Build PCDs can be overridden at
module scope. You can enable special ("exceptional") debug masks on a
module-by-module basis -- and that's something we use heavily.

For example, in my ad-hoc personal OVMF builds, I enable DEBUG_VERBOSE
indiscriminately, at the platform level, but then clear DEBUG_VERBOSE
for NvmExpressDxe, QemuVideoDxe, QemuRamfbDxe, the DXE Core,
PiSmmCpuDxeSmm, IoMmuDxe, AmdSevDxe, VariableSmm, VariableRuntimeDxe.

I use somewhat different module-scope overrides in my ArmVirtQemu
builds. In official RHEL builds, we use yet different module-scope debug
mask overrides.

For our specific case, our users would like the ability to enable/disable DEBUG mask flag bits dynamically.
Won't work, sorry (see above).

(At least given the current scope of the debug-related PCDs. If you'd
like to propose a new set of PCDs, so that SEC use some Fixed-At-Build
PCDs, but PEI and DXE use a different set of Dynamic PCDs, you can try
that; they'd have to be proposed for MdePkg. Good luck with that.

... At least my understanding is that "access method" is
platform-global, for any given PCD. I've never seen some modules use a
PCD as dynamic, and other modules use the same PCD as fixed. I could be
wrong about that, of course.)

In case of OVMF, you have some dynamic configurability -- if you do not
enable the QEMU debug console (QEMU debug port), then OVMF will throw
away the debug messages, and you won't pay for the IO Port accesses at
least. (They are very expensive under SEV!)

In case of ArmVirtQemu, I can't recommend anything though. In RHEL, we
offer a verbose build (for debugging, with some module-scope overrides)
and a silent build (which only emits DEBUG_ERROR, again with some
module-scope overrides).
One more thought, regarding fw_cfg-controlled DebugLib instances:

- fw_cfg access is unavailable in ArmVirtQemu before the DXE phase,

- on both Ovmf and ArmVirtQemu, the QemuFwCfgLib instances themselves
use DEBUGs, as a part of the fw_cfg interface detection. This would
create a circular dependency.

DebugLib is one of the lowest-level abstractions in edk2; it is supposed
to work when there are basically zero services available. (It also
requires a very primitive output device. ARM's PL011 is serial port is
already a stretch.)


Join to automatically receive all group messages.