Thanks for your interest Gerd, I added "-serial mon:stdio" to the qemu invocation and "console=ttyS0" to the -append line to capture all boot output for both good and bad cases and saved the results

Hello Tom, I don't think we should do an assert here and abort booting, failure here will simply disable live migration support but i don't think that it is such a fatal error that we should abort

They do contain UB, inherently from the combination of their prototype and their usage. Please refer to the new BZ added for V2: https://bugzilla.tianocore.org/show_bug.cgi?id=3542 I could only

The latter part is true only for Xcode-based toolchains, as far as I am aware now, and this is in fact the way it works right now. You are correct, but the NASM section name semantically translates

Yes, and ".rodata" is almost a synonym for "__DATA,__const", with a small exception [1]. Maybe it'd be clearer if the macro was renamed to "NASM_RODATA_SECTION_NAME", to indicate this is not just a

Hi Robinson, When we doing the internal test, the issue is found that py27 is blocked by this patch. You can reproduce the error with below steps: For Linux: [Error Reproduce steps] $ export

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3365 BIOS cannot find correct AcpiProcId in mApicIdMap because of there is no suitable map, that causes ACPI_BIOS_ERROR. Remove mApicIdMap for

Hi Jiewen, The intention of such API would be to ease debugging and auditing PCR attestation along the boot; it has been a common task while debugging several issues and TPM configurations. a)

Hi Jiewen, Indeed, this bug has existed for a long time in this code. What recently changed are the TPM configurations we are testing and exposed the issue; this can be reproduced when theBIOS

Hi, Nope. When you enable hyper-v emulation features you'll go find the kvm cpuid @ 0x40000000 and the hyper-v cpuid @ 0x40000100 (or the other way around, not sure). take care, Gerd

Hi, Root cause is not clear. Grab the kernel log ('dmesg') from a good and a bad boot and comparing them should give a clue. take care, Gerd

Ray, I made a detailed response about Mach-O with Xcode/clang and I don’t think patch works. Not sure if it breaks anything, but it puts things in the .data PE/COFF section. I’m also worried it

PeiFspWrapperHobProcessLib is currently set to depens on FspWrapperPlatformLib, but it does not use any of the functions implemented by that LibraryClass. This change removes that unneeded

Updates SA_MISC_PEI_PREMEM_CONFIG from revision 1 to revision 3. Add initialization of the policy values. Cc: Chasel Chiu <chasel.chiu@...> Cc: Michael Kubacki

An EFI Mach-O file does not contain a .rodata section. A Mach-O contains a __DATA segment that is broken up into sections. For a typical EFI image there are __const, __data, __bss sections in the

Sorry Mike, Do you have advice on how to deal with ECC reporting function naming issue on the 'main' function for unit test cases? So far, I think Wenyi has tried following the same pattern in file

The CM4 has a number of carrier boards with PCIe slots. With the PCIe changes in place its quite possible to utilize a NVMe root device. Lets allow people to boot from it. Reviewed-by: Andrei

The existing code fails to create/finish configuring the pcie subsystem if it fails to get a linkup. This is reasonable on the RPi4 because it generally won't happen, and the OS could not see the root

The CM4 has an actual PCIe slot, so the device filtering need to be a little less restrictive WRT busses with more than 1 device given that switches can now appear in the topology. Since it is

Since we plan on toggling between XHCI and PCI the PCI root needs to be in its own SSDT. This is all thats needed of UEFI. The SMC conduit is provided directly to the running OS. When the OS detects