aarch64: Support SMBIOS by yamahata · Pull Request #8786 · cloud-hypervisor/cloud-hypervisor

yamahata · 2026-08-25T08:52:59Z

The aarch64 guest gets the empty SMBIOS/DMI because cloud-hypervisor on aarch64
never passes the table to the guest BIOS (x86-64 cloud-hypervisor does).
Some guest software checks the environment via SMBIOS, E.g. the platform is KVM.
The lack of SMBIOS results in the guest software failing to identify the platform.
As a result, software initialization fails.

Compile smbios code for aarch64 in addition to x86_64.
Place the SMBIOS entry points and tables as follows.

Memory layout
Without this patch:

---------------------------- 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

With this patch:

---------------------------- 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

Choose this layout to keep the compatibility with the EDK2 without
patch. The alternative is to allocate, say 0x20_0000 region for
SMBIOS entry point and tables and push KERNEL_START. In such case,
the existing EDK2 CloudHv binary doesn't work with the new memory
layout.

The edk2 patch is at yamahata/edk2@bf24ccd.
The pull request for edk2 is at tianocore/edk2#13027.

Fixes #8716

rhakobyan

Thanks for the change. Quick question - is the motivation here to have systemd-detect-virt, etc. detect and report virt correctly?

yamahata · 2026-08-25T21:05:52Z

Thanks for the change. Quick question - is the motivation here to have systemd-detect-virt, etc. detect and report virt correctly?

My original motivation is the GPU driver. systemd-detect-virt etc is side-effect.

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). 37baf06 for x86 changed the version for the pre-2015 guest, but aarch64 doesn't have such guest predating SMBIOS 3.0. c98da33 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. [1] cloud-hypervisor/cloud-hypervisor#8786 [2] cloud-hypervisor/cloud-hypervisor#8716 Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>

rhakobyan · 2026-08-27T14:36:01Z

 with the older GRUB behavior, apply the same override. x86-64
 (`CLOUDHV.fd`) is unaffected as it does not enforce this NX policy.

+### SMBIOS on AArch64 guests


Wondering if the EDK2 patches should land first? Otherwise there's nothing consuming these at the moment.

Ok, let's see how the edk2 review will go.
tianocore/edk2#13027

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). 37baf06 for x86 changed the version for the pre-2015 guest, but aarch64 doesn't have such guest predating SMBIOS 3.0. c98da33 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. [1] cloud-hypervisor/cloud-hypervisor#8786 [2] cloud-hypervisor/cloud-hypervisor#8716 Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>

Only x86_64 supports SMBIOS table creation currently and the file, smbios.rs, is under arch/src/x86_64/ directory. Except the constant of layout::SMBIOS_START, the logic is generic. Move it out from arch/src/x86_64/ to arch/src/ so that it can be used for aarch64 with the path adjustment. This patch only moves the file. The file is compiled only for x86_64 yet. Later patch make it compile for aarch64 in addition to x86_64. Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai> Assisted-by: Claude:claude-fable-5 Claude-Code

As other places needs SMBIOS_START as GuestAddress, make x86_64 SMBIOS_START GuestAddress instead of u64 for simplicity. Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>

smbios.rs hardcodes the SMBIOS entry point address as x86 layout::SMBIOS_START (=0xf0000). In order to re-use the function to create the SMBIOS entry point and its tables for aarch64 which adopts the guest memory layout different from x86, make the SMBIOS entry point address parameter for setup_smbios(). Pass the address to the function. To keep tests working, define SMBIOS_START within unit_tests module. Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai> Assisted-by: Claude:claude-fable-5 Claude-Code

The current cloud-hypervisor doesn't provide the SMBIOS table to aarch64 guest. Some drivers reads the SMBIOS Type 0 (BIOS Information) virtual-machine bit to detect that it is running under a hypervisor. If it's not set, it falls back to the bare metal, and fails to initialize. Compile the SMBIOS table creator, smbios.rs, for aarch64, and call it to create the SMBIOS 3.0 entry point and its tables at the end of the ACPI tables. This is the ABI between cloud-hypervisor and the guest firmware (edk2 CloudHv). The patch to EDK2 is needed to teach EDK2 ClooudHv about SMBIOS 3.0 entry point. Memory layout Without this patch: ---------------------------- 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 With this patch: ---------------------------- 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 Choose this layout to keep the compatibility with the EDK2 without patch. The alternative is to allocate, say 0x20_0000 region for SMBIOS entry point and tables and push KERNEL_START. In such case, the existing EDK2 CloudHv binary doesn't work with the new memory layout. The existing --platform system_*/oem_strings options feed the aarch64 tables in the same way to the x86 through the PlatformConfig::smbios_config(). Fixes cloud-hypervisor#8716 Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai> Assisted-by: Claude:claude-fable-5 Claude-Code

Add size check if SMBIOS tables don't overflow from the given size. The check is at the end of the function for code simplicity with the accepting the overflow in the middle of the table creation. The alternative is to add size check to every sub function and pass down the end address. Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>

The guest should see the virtualized environment flag is set. Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>

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). 37baf06 for x86 changed the version for the pre-2015 guest, but aarch64 doesn't have such guest predating SMBIOS 3.0. c98da33 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. [1] cloud-hypervisor/cloud-hypervisor#8786 [2] cloud-hypervisor/cloud-hypervisor#8716 Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>

yamahata requested a review from a team as a code owner August 25, 2026 08:53

yamahata force-pushed the issue/202608/aarch64-smbios branch from e8d1a0b to 264da23 Compare August 25, 2026 09:03

rhakobyan reviewed Aug 25, 2026

View reviewed changes

Comment thread arch/src/smbios.rs Outdated

Comment thread arch/src/aarch64/layout.rs Outdated

Comment thread arch/src/aarch64/mod.rs Outdated

yamahata force-pushed the issue/202608/aarch64-smbios branch 2 times, most recently from 66ae998 to a1ecd57 Compare August 25, 2026 21:14

yamahata mentioned this pull request Aug 26, 2026

OvmfPkg, ArmVirtPkg: Add SMBIOS support to ArmVirtCloudHv tianocore/edk2#13027

Open

3 tasks

rhakobyan reviewed Aug 27, 2026

View reviewed changes

yamahata force-pushed the issue/202608/aarch64-smbios branch from a1ecd57 to 92c1beb Compare August 27, 2026 21:02

yamahata added 6 commits August 27, 2026 14:08

arch: x86_64: Make SMBIOS_START GuestAddress for simplicity

cc4b5e8

As other places needs SMBIOS_START as GuestAddress, make x86_64 SMBIOS_START GuestAddress instead of u64 for simplicity. Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>

arch: Add test case of smbios to check if virt flags is set

dc564b7

The guest should see the virtualized environment flag is set. Signed-off-by: Isaku Yamahata <iyamahata@crusoe.ai>

yamahata force-pushed the issue/202608/aarch64-smbios branch from 92c1beb to dc564b7 Compare August 27, 2026 21:09

Navigation Menu

Uh oh!

aarch64: Support SMBIOS - #8786

aarch64: Support SMBIOS#8786
yamahata wants to merge 6 commits into
cloud-hypervisor:mainfrom
yamahata:issue/202608/aarch64-smbios

yamahata commented Aug 25, 2026 •

edited

Loading

Uh oh!

rhakobyan left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yamahata commented Aug 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rhakobyan Aug 27, 2026

Uh oh!

yamahata Aug 27, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

yamahata commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rhakobyan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yamahata commented Aug 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rhakobyan Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

yamahata Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

yamahata commented Aug 25, 2026 •

edited

Loading