On 12/09/20 19:16, Eduardo Habkost wrote: > On Wed, Dec 09, 2020 at 09:42:25AM +0000, Daniel P. Berrangé wrote: >> On Tue, Dec 08, 2020 at 04:20:23PM -0500, Eduardo Habkost wrote: >>> Add command-line option that lets the SMBIOS entry point type to >>> be configured. >>> >>> SMBIOS 3.0 support is necessary to allow us to support more >>> than 720 VCPUs in x86_64, due to SMBIOS 2.1 table size limits. >>> >>> Note that it's still up to firmware to decide whether to generate >>> SMBIOS 2.1 and/or 3.0 entry points for the guest, using the >>> information contained in etc/smbios/smbios-anchor. OVMF, for >>> example, is able to generate both entry points, depending on the >>> value of PcdSmbiosEntryPointProvideMethod. >>> >>> The SMBIOS 3.0 entry point won't be enabled by default because it >>> is not supported yet by Seabios. This may be changed once >>> Seabios starts supporting SMBIOS 3.0 entry points. >>> >>> Signed-off-by: Eduardo Habkost <ehabk...@redhat.com> >>> --- >>> Laszlo, Philippe: do you know how exactly the value of >>> PcdSmbiosEntryPointProvideMethod is chosen when running OVMF? >> >> Laszlo proides alot of detail in my original proposal for >> selecting SMBIOS entry point here: >> >> https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg03347.html > > Thanks! > >> > [...] >>> diff --git a/qemu-options.hx b/qemu-options.hx >>> index 104632ea34..d2a973f8a7 100644 >>> --- a/qemu-options.hx >>> +++ b/qemu-options.hx >>> @@ -2294,7 +2294,9 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios, >>> " specify SMBIOS type 11 fields\n" >>> "-smbios >>> type=17[,loc_pfx=str][,bank=str][,manufacturer=str][,serial=str]\n" >>> " [,asset=str][,part=str][,speed=%d]\n" >>> - " specify SMBIOS type 17 fields\n", >>> + " specify SMBIOS type 17 fields\n" >>> + "-smbios entry-point-type=2.1|3.0\n" >>> + " specify SMBIOS entry point type\n", >> >> My previous patch: >> >> https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg03027.html >> >> exposed the entry point version as a property on the PC machine >> rather than the -smbios arg, principally because it is the machin >> setup code that currently defines what version is used via the calls >> to smbios_set_defaults(). >> >> IIUC from Laszlo's reply, SMBIOS 2.1 is not valid for AArch64 >> at all - they only support 3.0. So there's a small benefit from >> configuring this against the PC machine types, because it prevents >> ability to select 2.1 for ARM SMBIOS which would be invalid. > > Good point. It would also make it easier to change the machine > type default in the future. > > I will submit something based on your patches, instead. >
Thank you, Daniel, for finding that write-up; I've got it completely paged-out by now :) I don't have anything to add here, just confirming that I've read this thread quickly. Eduardo, if you have questions wrt. OVMF, please let me know; I'll try to find the time. Thanks! Laszlo
