Hi, I think the best documentation you can find is hw/acpi/bios-linker-loader.c in the qemu source tree. It's a mini-language telling the firmware about the allocations needed, about pointers (xsdt

Thanks Gerd for reviewing. Thanks. I was contemplating that, but wasn't sure (I only use OvmfPkgX64 and AmdSevX64 in my testing). Is it common in edk2? Would it apply to other OvmfPkg targets? I

Thanks much for the review comments. It will be fixed in the next version. Thanks Min

Yes, MPX is dead. Thank you to remove the MPX suggestion. And we could focus on PEI/DXE firstly. Thanks Steven Shi From: Pedro Falcato <pedro.falcato@...> Sent: Tuesday, March 29, 2022

Hi Gerd, Ok. I will leave it as is. Personally, I would like to use plain OVMF without any bhyve specific patches as firmware for bhyve. So, I want to go the qemu route but there's some more work to

Makes sense. Acked-by: Gerd Hoffmann <kraxel@...> Maybe also move this to a common include file, so it is less likely that they run out of sync again? take care, Gerd

Given that FW_CFG_MAX_CPUS is unused on qemu these days it is unlikely that reusing it causes problems. IIRC the problems mentioned in the comment only matter with VMs having > 255 vCPUs because

From: Corvin Köhne <CorvinK@...> QemuFwCfg is much more powerful than BhyveFwCtl. Sadly, BhyveFwCtl decided to use the same IO ports as QemuFwCfg. It's not possible to use both

Hi Gerd, Yes, BhyveFwCtl uses another signature. Best regards Corvin Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register

Hi Gerd, The FwCfgItem of this patch is used by bhyve to build the MADT. So, it's similar to the use case of FW_CFG_MAX_CPUS. At the moment, I'm using an additional bhyve specific FwCfgItem. I just

Hmm, so QemuFwCfg and BhyveFwCtl are incompatible but use the same ports? I guess the signature used is different then so the guest has a chance to figure which one is active? Assuming the above is

There is FW_CFG_NB_CPUS + FW_CFG_MAX_CPUS. ovmf uses different names, see OvmfPkg/Include/IndustryStandard/QemuFwCfg.h PlatformPei for qemu uses QemuFwCfgItemSmpCpuCount aka FW_CFG_NB_CPUS, which is

Acked-by: Gerd Hoffmann <kraxel@...>

Apply the workaround only in case the compiler is gcc. Fixes builds with clang. Fixes: 22130dcd98b4 ("Basetools: turn off gcc12 warning") Reported-by: Rebecca Cran <rebecca@...> Signed-off-by:

REF： https://bugzilla.tianocore.org/show_bug.cgi?id=3882 UefiCpuPkg define a new Protocol with the new services SmmWaitForAllProcessor(), which can be used by SMI handler to optionally wait for

From: Corvin Köhne <CorvinK@...> QemuFwCfg is much more powerful than BhyveFwCtl. Sadly, BhyveFwCtl decided to use the same IO ports as QemuFwCfg. It's not possible to use both

Hi, I'm going to add QemuFwCfg support to bhyve. See https://reviews.freebsd.org/D31578. Therefore, this patch for OVMF is neccessary to work properly. There's one open point on that patch and

Hi Guo, Sorry for the late response. Just as we discussed today, and also from the suggestions by Ray, in the new patch I will 1. changed "UNIVERSAL_PAYLOAD_ DEBUG_PRINT_ERROR_LEVEL" to

REF： https://bugzilla.tianocore.org/show_bug.cgi?id=3882 UefiCpuPkg define a new Protocol with the new services SmmWaitForAllProcessor(), which can be used by SMI handler to optionally wait for

REF： https://bugzilla.tianocore.org/show_bug.cgi?id=3882 UefiCpuPkg define a new Protocol with the new services SmmWaitForAllProcessor(), which can be used by SMI handler to optionally wait for