BTW, it seems to me that QEMU fwcfg is only used for Xen Direct Kernel Boot. However, per xl.cfg manpage, it's possible to turn on or off S3 support by setting "acpi_s3" in xl.cfg, but PcdAcpiS3Enable

To be honest, I don't have Xen environment and didn't realize that it's about direct kernel boot until looking into another bug report. I just compared InitializeXenPlatform() with InitializePlatform(

Without QemuKernelLoaderFsDxe, QemuLoadKernelImage() couldn't download the kernel, initrd, and kernel command line from QEMU's fw_cfg. Cc: Ard Biesheuvel <ardb+tianocore@...> cc: Jordan Justen

There are several functions in OvmfPkg/Library using QemuFwCfgS3Enabled() to detect the S3 support status. However, in MdeModulePkg, PcdAcpiS3Enable is used to check S3 support. Since InitializeXenPla

Thanks for the information. I was reviewing the libvirt descriptor for ovmf and wondering if it's ready for the "acpi-s4" tag. Maybe it's a good to give it a try. Thanks, Gary Lin

Hi, Years ago, the bug(*) for PEI variable driver was filed against OVMF and it used to be one reason to block S4 support in OVMF. The bug is fixed now, and there are several MemTypeInfo fixes merged

Hi Laszlo, Thanks for noticing me :) I just tested the patch with the ISO files with SLE15-SP2, openSUSE Leap 15.2, Fedora 32, and ubuntu 20.04, and the VM loads them without any problem, so there is

Hi, My colleagues recently raised a question to me: does UEFI enforce the x509v3 extended key usage check, such as CodeSigning, for Secure Boot? (Some certification such as NIAP OS PP requires the OS

Looks good to me :) Reviewed-by: Gary Lin <glin@...>

I've tested the following ISO images and all booted as expected. openSUSE Leap 15.2 SLES 15-SP2 Fedora 32 Ubuntu 20.04 Tested-by: Gary Lin <glin@...>

Thanks for the patches. After applying this patch series, the firmware recognizes openSUSE/SUSE iso images again. Tested-by: Gary Lin <glin@...>

The status codes of EFI_TCG2_PROTOCOL.SubmitCommand() defined in "TCG EFI Protocol Specification for TPM 2.0" Version 1.0 Revision 0.13 are EFI_SUCCESS, EFI_DEVICE_ERROR, EFI_INVALID_PARAMETER, and EF

Cc: Jordan Justen <jordan.l.justen@...> Cc: Laszlo Ersek <lersek@...> Cc: Ard Biesheuvel <ard.biesheuvel@...> Signed-off-by: Gary Lin <glin@...> Reviewed-by: Laszlo Ersek <lersek

This is the second part of LsiScsiPassThru(). LsiScsiProcessRequest() is added to translate the SCSI Request Packet into the LSI 53C895A commands. This function utilizes the so-called Script buffer to

This is the first part of LsiScsiPassThru(). Before processing the SCSI Request packet, we have to make sure whether the packet is valid or not. v2: Make LsiScsiPassThru() return EFI_UNSUPPORTED since

Map DMA buffer and perpare for the implementation of LsiScsiPassThru(). v2: - Replace 0x10000 with SIZE_64KB macro for the DMA buffer data array - Remove DUAL_ADDRESS_CYCLE from PciIo since we don't r

Open PciIo protocol and use it to initialize the device. The initialization of LSI 53C895A is simple: just set the SRST bit in Interrupt Status Zero register to reset the device. v2: - Use the BITx ma

Implement LsiScsiGetNextTargetLun(), LsiScsiBuildDevicePath(), LsiScsiGetTargetLun(), and LsiScsiGetNextTarget() to report Targets and LUNs and build the device path. This commit also introduces two P

Partially implement LsiScsiControllerStart() and LsiScsiControllerStop() to insert the scaffolding of EXT_SCSI_PASS_THRU functions. v3: Squash the newline below the declaration of LSI_SCSI_FROM_PASS_T

Implement LsiScsiControllerSupported() to probe the PCI ID and look for LSI 53C895A. Cc: Jordan Justen <jordan.l.justen@...> Cc: Laszlo Ersek <lersek@...> Cc: Ard Biesheuvel <ard.biesheuv