When creating VMs with a large amount of RAM, the SMBIOS tables created by QEMU may contain duplicate handle IDs. Problem diagnosed at: https://bugzilla.redhat.com/show_bug.cgi?id=1904267#c51 Copying from original report: (In reply to Eduardo Habkost) > (In reply to Brian Payton) > > ASSERT_EFI_ERROR (Status = Already started) > > ASSERT > > /builddir/build/BUILD/edk2-ca407c7246bf/OvmfPkg/SmbiosPlatformDxe/ > > SmbiosPlatformDxe.c(125): !EFI_ERROR (Status) > > This one might be an unexpected duplicate SMBIOS handle in the tables > generated by QEMU. I will double-check the SMBIOS table generation code to > be sure. Yes, this is where the problem comes from: static void smbios_build_type_17_table(unsigned instance, uint64_t size) { SMBIOS_BUILD_TABLE_PRE(17, 0x1100 + instance, true); /* required */ ... static void smbios_build_type_19_table(unsigned instance, uint64_t start, uint64_t size) { SMBIOS_BUILD_TABLE_PRE(19, 0x1300 + instance, true); /* required */ Using the current handle assignment code, we can have only up to 512 DIMM slots before their type 17 SMBIOS handles conflict with the type 19 table handles. QEMU has DIMM sizes hardcoded to 16GB, which means an 8TB guest will hit the limit.
Assigning to Amnon for reassignment, NB: module is maintained by mst.
I am going to take a stab at this. Could not assign the bug to myself unfortunately (I am not redhat :()
The problem is in this code in smbios_get_tables() dimm_cnt = QEMU_ALIGN_UP(current_machine->ram_size, MAX_DIMM_SZ) / MAX_DIMM_SZ; smbios_build_type_16_table(dimm_cnt); for (i = 0; i < dimm_cnt; i++) { smbios_build_type_17_table(i, GET_DIMM_SZ); } for (i = 0; i < mem_array_size; i++) { smbios_build_type_19_table(i, mem_array[i].address, mem_array[i].length); } Clearly after 512 iterations of the first loop, the two tables will collide as 0x1100 + 512 = 0x1300.
Sent a patch in the mailing list: https://lists.gnu.org/archive/html/qemu-devel/2022-02/msg00358.html
@ailan@ailan please re-assign this ticket to me.
(In reply to Ani Sinha from comment #5) > @ailan@ailan please re-assign this ticket to me. Done. Thank you for taking it!
Moving this to rhel9, if the fix is going to come as part of the rebase, then we can mark this as TestOnly. For rhel8, we will create a clone if required.
A fix has been pushed upstream: https://git.qemu.org/?p=qemu.git;a=commit;h=a379d4550c4a949bb1ca51bc5272d68b4a619b18 . QE, please verify.
(In reply to Ani Sinha from comment #12) > A fix has been pushed upstream: > https://git.qemu.org/?p=qemu.git;a=commit; > h=a379d4550c4a949bb1ca51bc5272d68b4a619b18 . QE, please verify. Thanks, Ani, for getting the fix upstream. I am moving this BZ back to ASSIGNED. Once the patch is merged upstream please add the commit ID in the comment and then move the BZ to POST. Since the patches will automatically come via reabse there is no action required after that. QE will test it as the images are available. Igor has already provided a repo with the fix to the reporter, and hopefully, we will hear something soon.
@nilal the patch has already been merged upstream. That is why I updated the ticket. Commit ID: a379d4550c4a949bb1ca51bc5272d68b4a619b18 as I have mentioned above.
(In reply to Ani Sinha from comment #14) > @nilal the patch has already been merged upstream. That is why I > updated the ticket. > > Commit ID: a379d4550c4a949bb1ca51bc5272d68b4a619b18 as I have mentioned > above. Got it, thanks for the correction.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: qemu-kvm security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:7967