What were you trying to do that didn't work?

boot a vm with large cpu (such as vcpu = 512), checking the smbios version with smbiosview under uefishell. 

Unable to start the VM on rhel10.1 and rhel10.2 for 10 minutes or longer, which resulted in the inability to obtain the smbios version.

What is the impact of this issue to you?

It doesn't have a significant impact on me. I can also use -machine smbios-entry-point-type=64 to force smbios 3.0.

Please provide the package NVR for which the bug is seen:

RHEL-10.2
Versions:
kernel-6.12.0-150.el10.x86_64
qemu-kvm-10.1.0-4.el10
edk2-ovmf-20250822-3.el10.noarch

How reproducible is this bug?:

100%

Steps to reproduce

1. Boot a vm with 512 vCPUs. For full command line, please refer to smbios_3.0_test.sh

-smp 510,maxcpus=510,cores=255,threads=1,dies=1,sockets=2  \
-global mch.extended-tseg-mbytes=48 \ 

Expected results

Although the startup is a bit slow, the vm can still be started in about 5 minutes.

Then I check the version with smbiosview under uefishell to get the version: 3.0

Actual results

unable to start the VM for 10 minutes or longer, which resulted in the inability to obtain the smbios version.

edk2 log: edk2_rhel10.2.log

looking at the time stamps there are multi-minute delays (15:26:42 -> 15:31:20 and 15:31:25 -> 15:34:45)

2025-11-07 15:26:33: Variable SecureBoot is 0
2025-11-07 15:26:33: Variable SecureBootEnable is 0
2025-11-07 15:26:33: Var
2025-11-07 15:26:42: iable CustomMode is 0
2025-11-07 15:31:20: Variable VendorKeys is 1
2025-11-07 15:31:20: Variable driver will work with auth variable support
2025-11-07 15:31:24: !
2025-11-07 15:31:24: InstallProtocolInterface: 93BA1826-DFFB-45DD-82A7-E7DCAA3BBDF3 0
2025-11-07 15:31:25: InstallProtocolInterface: 3868FC3B-7E45-43A7-906C-4BA47DE1754D 0
2025-11-07 15:34:45: Loading driver FA20568B-548B-4B2B-81EF-1BA08D4A3CEC
2025-11-07 15:34:45: CcMeasurementProtocol is not installed. - Not Found 

Dump EFI variable stores

# virt-fw-dump -i /root/avocado/data/avocado-vt/avocado-vt-vm1_rhel102-64-virtio-scsi-ovmf_qcow2_filesystem_VARS.raw
image=/root/avocado/data/avocado-vt/avocado-vt-vm1_rhel102-64-virtio-scsi-ovmf_qcow2_filesystem_VARS.raw
  volume=guid:NvData offset=0x0 size=0x84000 hlen=0x48 xoff=0x0 rev=2 blocks=132*4096 used=48.5%
    nvdata=guid:AuthVars size=0x3ffb8 format=0x5a state=0xfe
      variable=guid:EfiCustomModeEnable nsize=0x16 dsize=0x1 attr=0x3 name=CustomMode (ok)
        bool: off
      variable=guid:EfiCertDb nsize=0xe dsize=0x4 attr=0x27 name=certdb (ok)
        dword: 0x00000004
      variable=9073e4e0-60ec-4b6e-9903-4c223c260f3c nsize=0x1a dsize=0x1 attr=0x23 name=VendorKeysNv (ok)
        byte: 0x01
      end of variable list at offset 0xfc 

Additional information:

also hit it on rhel-10.1

Versions:
kernel-6.12.0-124.8.1.el10_1.x86_64
qemu-kvm-10.0.0-14.el10_1
edk2-ovmf-20250523-2.el10_1.2

edk2 log: edk2_rhel10.1.log

It works on rhel-10.0

Versions:
kernel-6.12.0-55.46.1.el10_0.x86_64
qemu-kvm-9.1.0-15.el10_0.5
edk2-ovmf-20241117-2.el10_0.2

edk2 log: edk2_rhel10.0.log

PS: Because I usually don't have such a large machine when running test case, I often use over commit to test. Such as booting a vm on a host with 40 CPUs. I also tested it in this way here.