On 09/20/19 11:28, Laszlo Ersek wrote:
On 09/20/19 10:28, Igor Mammedov wrote:I've got good results. For this (1/2) QEMU patch:On Thu, 19 Sep 2019 19:02:07 +0200OK. Let's go with 128KB for now. Shrinking the area is always easier
Tested-by: Laszlo Ersek <lersek@...>
I tested the following scenarios. In every case, I verified the OVMF
log, and also the "info mtree" monitor command's result (i.e. whether
"smbase-blackhole" / "smbase-window" were disabled or enabled). Mostly,
I diffed these text files between the test scenarios (looking for
desired / undesired differences). In the Linux guests, I checked /
compared the dmesg too (wrt. the UEFI memmap).
- unpatched OVMF (regression test), Fedora guest, normal boot and S3
- patched OVMF, but feature disabled with "-global mch.smbase-smram=off"
(another regression test), Fedora guest, normal boot and S3
- patched OVMF, feature enabled, Fedora and various Windows guests
(win7, win8, win10 families, client/server), normal boot and S3
- a subset of the above guests, with S3 disabled (-global
ICH9-LPC.disable_s3=1), and obviously S3 resume not tested
SEV: used 5.2-ish Linux guest, with S3 disabled (no support under SEV
for that now):
- unpatched OVMF (regression test), normal boot
- patched OVMF but feature disabled on the QEMU cmdline (another
regression test), normal boot
- patched OVMF, feature enabled, normal boot.
I plan to post the OVMF patches tomorrow, for discussion.
(It's likely too early to push these QEMU / edk2 patches right now -- we
don't know yet if this path will take us to the destination. For now, it
certainly looks great.)