Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: 9c5e32857f647375ef8e505977dbcb5e18ae2ef2
https://github.com/tianocore/edk2/commit/9c5e32857f647375ef8e505977dbcb5e18ae2ef2
Author: Isaku Yamahata <[email protected]>
Date: 2026-09-11 (Fri, 11 Sep 2026)
Changed paths:
M OvmfPkg/Include/IndustryStandard/CloudHv.h
M OvmfPkg/OvmfPkg.dec
M OvmfPkg/SmbiosPlatformDxe/CloudHv.c
M OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
Log Message:
-----------
OvmfPkg/SmbiosPlatformDxe: Make the CloudHv SMBIOS address a PCD
SmbiosPlatformDxe/CloudHv.c reads the SMBIOS 3.0 entry point from the
hardcoded CLOUDHV_SMBIOS_ADDRESS (0xf0000), which is specific to X64.
Introduce PcdCloudHvSmbiosBaseAddress in OvmfPkg/OvmfPkg.dec with the
default value 0xf0000 so that X64 is unaffected, read it with
PcdGet64(), and drop the now-unused CLOUDHV_SMBIOS_ADDRESS.
This lets other CloudHv platforms places the tables at a different
address.
Signed-off-by: Isaku Yamahata <[email protected]>
Commit: 69f6970bd95c008cf5b52a2407c5ed84fc2e4aa6
https://github.com/tianocore/edk2/commit/69f6970bd95c008cf5b52a2407c5ed84fc2e4aa6
Author: Isaku Yamahata <[email protected]>
Date: 2026-09-11 (Fri, 11 Sep 2026)
Changed paths:
M ArmVirtPkg/ArmVirtCloudHv.dsc
M ArmVirtPkg/ArmVirtCloudHv.fdf
Log Message:
-----------
ArmVirtPkg/ArmVirtCloudHv: Add SMBIOS support
Wire MdeModulePkg/SmbiosDxe and OvmfPkg/SmbiosPlatformDxe into the
ArmVirtCloudHv platform so that aarch64 Cloud Hypervisor guests get
SMBIOS tables, matching the existing X64 CloudHv behavior.
aarch64 cloud-hypervisor side change can be found at [1] and [2].
They are still open at the moment.
The initial guest memory layout is as follows.
Memory layout without the cloud-hypervisor patch series:
---------------------------- FDT_START = RAM_START = 0x4000_0000
FDT size = 0x20_0000
---------------------------- ACPI_START = 0x4020_0000
ACPI table size = 0x20_0000
---------------------------- KERNEL_START = 0x4040_0000
the kernel
Memory layout with the cloud-hypervisor patch series:
---------------------------- FDT_START = RAM_START = 0x4000_0000
FDT size = 0x20_0000
---------------------------- ACPI_START = 0x4020_0000
ACPI table size = 0x20_0000 - 0x1_0000
---------------------------- SMBIOS_START = 0x403F_0000
SMBIOS 3.0 entry point/table size = 0x1_0000
---------------------------- KERNEL_START = 0x4040_0000
the kernel
The ACPI table size reduction is made by the cloud-hypervisor side [1].
This layout keeps the compatibility with the EDK2 without this
patch. The existing EDK2 CloudHV binary should keep working (with the
empty SMBIOS in the guest). The updated size for ACPI table for 2MiB -
64KiB and SMBIOS for 64KiB would be enough at this point because the
size for SMBIOS for x86 is 64KiB (0xf0000 segment). The alternative is
to allocate, say 0x20_0000 region for SMBIOS and push KERNEL_START. In
such case, the existing EDK2 CloudHv binary doesn't work with the new
memory layout.
There are several change points in the ArmVirtCloudHv.dsc:
SMBIOS base address: override PcdCloudHvSmbiosBaseAddress = 0x403F0000,
the PCD introduced by the previous patch. This is ABI between
cloud-hypervisor and guest firmware.
QEMU fw-cfg: Use the QemuFwCfgLibNull mapping as cloud-hypervisor
doesn't provide qemu fw-cfg by default. (It's required to link
SmbiosPlatformDxe/Qemu.c).
Host bridge device id: Statically set PcdOvmfHostBridgePciDevId =
CLOUDHV_DEVICE_ID (0x0D57) because ArmVirtCloudHv has no host bus
probe by construction unlike X64 runtime probe by OvmfPkg/PlatformPei.
Without this statically setting, the execution path goes to QEMU
fw_cfg path which isn't supported.
SMBIOS version/DocRev: Followed ArmVirtQemu (0x0300) rather than the
X64 CloudHv (0x0208). 37baf06b44 for x86 changed the version for the
pre-2015 guest, but aarch64 doesn't have such guest predating SMBIOS
3.0. c98da3345a kept 0x0300 for ArmVirtQemu.
Verified on a aarch64 host: the guest reports "SMBIOS 3.0.0 present."
and "DMI: Cloud Hypervisor cloud-hypervisor"; without the
PcdSmbiosVersion pin it reports 3.3.0.
The command line looks like the followings. Those options are all
optional. Even without those options, cloud-hypervisor creates SMBIOS
table with firmware characteristics extension with bit 4 a virtual
machine set so that the software in the guest can know that it's running
in virtual environment.
cloud-hypervisor --platform \
system_manufacturer=<dmi_system_manufacturer>,\
system_product_name=<dmi_system_product_name>,\
system_version=<dmi_system_version>,\
system_serial_number=<dmi_system_serial_number>,\
system_uuid=<dmi_system_uuid>,\
system_sku_number=<dmi_system_sku_number>,\
system_family=<dmi_system_family>,\
oem_strings=<list_of_strings>,\
chassis_asset_tag=<dmi_chassis_asset_tag> \
(other options).
[1] https://github.com/cloud-hypervisor/cloud-hypervisor/pull/8786
[2] https://github.com/cloud-hypervisor/cloud-hypervisor/issues/8716
Signed-off-by: Isaku Yamahata <[email protected]>
Compare: https://github.com/tianocore/edk2/compare/664068240f91...69f6970bd95c
To unsubscribe from these emails, change your notification settings at
https://github.com/tianocore/edk2/settings/notifications
_______________________________________________
edk2-commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-commits