Synchronize with edk2 package where StandaloneMmCpu component has moved from StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf to

This series brings support for building PlatformStandaloneMmRpmb for 32bit Arm architectures. This series is based on series tracked through [1] in edk2 that allows to build StandaloneMm package for

Installation is a platform decision. The buried dependency on boot mode in this particular function is just a roadblock platforms have to work around. The role of this API is to install the

There is not a SmmAccess PEIM in IntelSiliconPkg. There is a SmmAccessDxe

Hi Ard, Yeah, this is a good point. Greg and I offline discussed this as well. If we don't miss anything, only applying this patch without platform changes should be fine. There should be no behavior

<samer.el-haj-mahmoud@...> wrote: OK, I stand corrected again :-) Marcin, I won't object further to these additions -please respin the patch on top of current edk2-platform and I will apply it

Apologies for the tardiness in replying to this. Please see my comments below.

There's no definition of a disk device in here. Which looks like why this failed. Where's the vmm supposed to get /dev/sda from? It sort of seems like the CD rom boot script thinks it was mounted

Makes sense. Thanks, Tom

Ah, thanks. I just saw the comment above get_out_of_range_cpuid_entry() in arch/x86/kvm/cpuid.c where HyperV would get the 0x40000000-0x400000ff range and KVM would then get the 0x40000100-0x400001ff

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