Re: [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Laszlo Ersek <lersek@redhat.com>]

On 01/09/19 11:28, Ard Biesheuvel wrote:
> On Wed, 9 Jan 2019 at 10:44, Laszlo Ersek <lersek@redhat.com> wrote:

>> But, it's still not clear to me (without trying) whether I should
>> resolve MmServicesTableLib  for DXE_SMM_DRIVER in addition to
>> SmmServicesTableLib, or in its place. I'd prefer not experimenting with
>> this myself; I'd just like to apply the series, and build & test it. :)
>>
> 
> At the moment, you will need both resolutions for DXE_SMM_DRIVERS
> globally. Based on the outcome of the review of this series, this is
> something we will need to clean up going forward, but currently, even
> the drivers that are updated to use MmServicesTableLib pull in
> libraries that depend on SmmServicesTableLib.
> 
> This should be a rather straight-forward search/replace operation
> [famous last words], and I can commit to dedicating some of my time to
> getting this fixed throughout, at least to the point where modules
> that consume MmServicesTableLib no longer have to supply a resolution
> for SmmServicesTableLib as well.
> 
> So, I will include a patch in the next revision of the series.

Great, thank you. This is exactly the info I needed.

> In the mean time, the hunk below should suffice to complete your regression
> testing.
> 
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -391,6 +391,7 @@
>    HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>    SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>    SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> +  MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
>  !ifdef $(DEBUG_ON_SERIAL_PORT)
>    DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>  !else
> 

I'll replicate this to the other two DSC files [*], and then retry the
tests.

[*] SMM in OVMF has a non-intuitive restriction, in relation to X64 PEI.
SMM "just works" in the IA32 and IA32X64 builds, however, in the X64
build, one has to disable S3 support on the QEMU command line, or else
we hang the boot intentionally. See commit 5133d1f1d297 ("OvmfPkg:
replace README fine print about X64 SMM S3 with PlatformPei check",
2015-11-30).

For this reason, the IA32X64 build is considered the most-featureful, if
-D SMM_REQUIRE is desired.


For those that insist on the X64 build nevertheless, OvmfPkg/README
documents the QEMU option that disables S3, on the Q35 machine type,
which is required for SMM anyway:

  -global ICH9-LPC.disable_s3=1

When using libvirt, the matching knob is:

https://libvirt.org/formatdomain.html#elementsPowerManagement

<pm>
  <suspend-to-mem enabled='no'/>
</pm>


Personally, I focus my SMM testing on IA32 and IA32X64; I almost never
test SMM in the X64 build. This is because S3 has historically proved
very effective at triggering multiprocessing bugs in core SMM code, and
in general UefiCpuPkg infrastructure. Thus, my SMM regression tests:

https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

always include S3 suspend/resume, and that precludes the X64 build of OVMF.

... Sorry about the wall of text, I just wanted to explain why precisely
the short hunk you pasted is unhelpful in this case. Obviously, it does
answer my question, I can copy the class resolution to the other two DSC
files, and in the final OvmfPkg patch, we should update all three DSC files.

I'll be back with test results later.

Thanks!
Laszlo