aboutsummaryrefslogtreecommitdiff
path: root/hw/smbios
AgeCommit message (Collapse)AuthorFilesLines
2024-06-19hw/smbios: Remove 'smbios_uuid_encoded', simplify smbios_encode_uuid()Philippe Mathieu-Daudé1-6/+3
'smbios_encode_uuid' is always true, remove it, simplifying smbios_encode_uuid(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20240617071118.60464-13-philmd@linaro.org>
2024-06-19hw/smbios: Remove 'uuid_encoded' argument from smbios_set_defaults()Philippe Mathieu-Daudé1-4/+2
'uuid_encoded' is always true, remove it. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20240617071118.60464-12-philmd@linaro.org>
2024-03-26hw/smbios: add stub for smbios_get_table_legacy()Igor Mammedov1-0/+5
QEMU build fails with hw/i386/fw_cfg.c:74: undefined reference to `smbios_get_table_legacy' when it's built with only 'microvm' enabled i.e. with config patch +++ b/configs/devices/i386-softmmu/default.mak @@ -26,7 +26,7 @@ # Boards: # -CONFIG_ISAPC=y -CONFIG_I440FX=y -CONFIG_Q35=y +CONFIG_ISAPC=n +CONFIG_I440FX=n +CONFIG_Q35=n It happens because I've fogotten/lost smbios_get_table_legacy() stub. Fix it by adding missing stub as Philippe suggested. Fixes: b42b0e4daaa5 "smbios: build legacy mode code only for 'pc' machine" Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-ID: <20240326122630.85989-1-imammedo@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-03-18smbios: add extra comments to smbios_get_table_legacy()Igor Mammedov1-0/+7
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20240314152302.2324164-22-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: error out when building type 4 table is not possibleIgor Mammedov1-2/+12
If SMBIOS v2 version is requested but number of cores/threads are more than it's possible to describe with v2, error out instead of silently ignoring the fact and filling core/thread count with bogus values. This will help caller to decide if it should fallback to SMBIOSv3 when smbios-entry-point-type='auto' Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-18-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: in case of entry point is 'auto' try to build v2 tables 1stIgor Mammedov1-3/+49
QEMU for some time now uses SMBIOS 3.0 for PC/Q35 machines by default, however Windows has a bug in locating SMBIOS 3.0 entrypoint and fails to find tables when booted on SeaBIOS (on UEFI SMBIOS 3.0 tables work fine since firmware hands over tables in another way) Missing SMBIOS tables may lead to some issues for guest though (worst are: possible reactiveation, inability to get virtio drivers from 'Windows Update') It's unclear at this point if MS will fix the issue on their side. So instead of it (or rather in addition) this patch will try to workaround the issue. aka, use smbios-entry-point-type=auto to make QEMU try generating conservative SMBIOS 2.0 tables and if that fails (due to limits/requested configuration) fallback to SMBIOS 3.0 tables. With this in place majority of users will use SMBIOS 2.0 tables which work fine with (Windows + legacy BIOS). The configurations that is not to possible to describe with SMBIOS 2.0 will switch automatically to SMBIOS 3.0 (which will trigger Windows bug but there is nothing QEMU can do here, so go and aks Microsoft to real fix). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-17-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: clear smbios_type4_count before building tablesIgor Mammedov1-0/+1
it will help to keep type 4 tables accounting correct in case SMBIOS tables are built multiple times. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-15-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: get rid of global smbios_ep_typeIgor Mammedov2-13/+16
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-14-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: handle errors consistentlyIgor Mammedov2-20/+36
Current code uses mix of error_report()+exit(1) and error_setg() to handle errors. Use newer error_setg() everywhere, beside consistency it will allow to detect error condition without killing QEMU and attempt switch-over to SMBIOS3.x tables/entrypoint in follow up patch. while at it, clear smbios_tables pointer after freeing. that will avoid double free if smbios_get_tables() is called multiple times. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-13-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: build legacy mode code only for 'pc' machineIgor Mammedov5-163/+201
basically moving code around without functional change. And exposing some symbols so that they could be shared between smbbios.c and new smbios_legacy.c plus some meson magic to build smbios_legacy.c only for 'pc' machine and otherwise replace it with stub if not selected. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-12-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: rename/expose structures/bitmaps used by both legacy and modern codeIgor Mammedov1-60/+53
As a preparation to move legacy handling into a separate file, add prefix 'smbios_' to type0/type1/have_binfile_bitmap/have_fields_bitmap and expose them in smbios.h so that they can be reused in legacy and modern code. Doing it as a separate patch to avoid rename cluttering follow-up patch which will move legacy code into a separate file. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-11-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: add smbios_add_usr_blob_size() helperIgor Mammedov1-4/+14
it will be used by follow up patch when legacy handling is moved out into a separate file. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-10-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: don't check type4 structures in legacy modeIgor Mammedov1-4/+14
legacy mode doesn't support structures of type 2 and more, and CLI has a check for '-smbios type' option, however it's still possible to sneak in type4 as a blob with '-smbios file' option. However doing the later makes SMBIOS tables broken since SeaBIOS doesn't expect that. Rather than trying to add support for type4 to legacy code (both QEMU and SeaBIOS), simplify smbios_get_table_legacy() by dropping not relevant check in legacy code and error out on type4 blob. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-9-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: avoid mangling user provided tablesIgor Mammedov1-88/+93
currently smbios_entry_add() preserves internally '-smbios type=' options but tables provided with '-smbios file=' are stored directly into blob that eventually will be exposed to VM. And then later QEMU adds default/'-smbios type' entries on top into the same blob. It makes impossible to generate tables more than once, hence 'immutable' guard was used. Make it possible to regenerate final blob by storing user provided blobs into a dedicated area (usr_blobs) and then copy it when composing final blob. Which also makes handling of -smbios options consistent. As side effect of this and previous commits there is no need to generate legacy smbios_entries at the time options are parsed. Instead compose smbios_entries on demand from usr_blobs like it is done for non-legacy SMBIOS tables. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-8-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: get rid of smbios_legacy globalIgor Mammedov1-20/+15
clean up smbios_set_defaults() which is reused by legacy and non legacy machines from being aware of 'legacy' notion and need to turn it off. And push legacy handling up to PC machine code where it's relevant. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-7-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: get rid of smbios_smp_sockets globalIgor Mammedov1-13/+9
it makes smbios_validate_table() independent from smbios_smp_sockets global, which in turn lets smbios_get_tables() avoid using not related legacy code. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-6-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: cleanup smbios_get_tables() from legacy handlingIgor Mammedov1-6/+0
smbios_get_tables() bails out right away if leagacy mode is enabled and won't generate any SMBIOS tables. At the same time x86 specific fw_cfg_build_smbios() will genarate legacy tables and then proceed to preparing temporary mem_array for useless call to smbios_get_tables() and then discard it. Drop legacy related check in smbios_get_tables() and return from fw_cfg_build_smbios() early if legacy tables where built without proceeding to non legacy part of the function. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-5-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18SMBIOS: fix long linesMichael S. Tsirkin1-3/+6
Break up long lines to fit under 80/90 char limit. Fixes: 04f143d828 ("Implement SMBIOS type 9 v2.6") Fixes: 735eee07d1 ("Implement base of SMBIOS type 9 descriptor.") Cc: "Felix Wu" <flwu@google.com> Cc: Nabih Estefan <nabihestefan@google.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12Implement SMBIOS type 9 v2.6Felix Wu1-3/+46
Signed-off-by: Felix Wu <flwu@google.com> Signed-off-by: Nabih Estefan <nabihestefan@google.com> Message-Id: <20240221170027.1027325-3-nabihestefan@google.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12Implement base of SMBIOS type 9 descriptor.Felix Wu1-0/+99
Version 2.1+. Signed-off-by: Felix Wu <flwu@google.com> Signed-off-by: Nabih Estefan <nabihestefan@google.com> Message-Id: <20240221170027.1027325-2-nabihestefan@google.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-02-13hw/smbios: Fix port connector option validationAkihiko Odaki1-0/+6
qemu_smbios_type8_opts did not have the list terminator and that resulted in out-of-bound memory access. It also needs to have an element for the type option. Cc: qemu-stable@nongnu.org Fixes: fd8caa253c56 ("hw/smbios: support for type 8 (port connector)") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-13hw/smbios: Fix OEM strings table option validationAkihiko Odaki1-0/+6
qemu_smbios_type11_opts did not have the list terminator and that resulted in out-of-bound memory access. It also needs to have an element for the type option. Cc: qemu-stable@nongnu.org Fixes: 2d6dcbf93fb0 ("smbios: support setting OEM strings table") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-02-09smbios: function to set default processor familyHeinrich Schuchardt1-0/+7
Provide a function to set the default processor family. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20240123184229.10415-3-heinrich.schuchardt@canonical.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09smbios: add processor-family optionHeinrich Schuchardt1-2/+11
For RISC-V the SMBIOS standard requires specific values of the processor family value depending on the bitness of the CPU. Add a processor-family option for SMBIOS table 4. The value of processor-family may exceed 255 and therefore must be provided in the Processor Family 2 field. Set the Processor Family field to 0xFE which signals that the Processor Family 2 is used. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20240123184229.10415-2-heinrich.schuchardt@canonical.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-31meson: remove CONFIG_ALLPaolo Bonzini1-5/+0
CONFIG_ALL is tricky to use and was ported over to Meson from the recursive processing of Makefile variables. Meson sourcesets however have all_sources() and all_dependencies() methods that remove the need for it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-09-29hw/acpi: changes towards enabling -Wshadow=localAni Sinha1-18/+19
Code changes in acpi that addresses all compiler complaints coming from enabling -Wshadow flags. Enabling -Wshadow catches cases of local variables shadowing other local variables or parameters. These makes the code confusing and/or adds bugs that are difficult to catch. See also Subject: Help wanted for enabling -Wshadow=local Message-Id: <87r0mqlf9x.fsf@pond.sub.org> https://lore.kernel.org/qemu-devel/87r0mqlf9x.fsf@pond.sub.org The code is tested to build with and without the flag turned on. CC: Markus Armbruster <armbru@redhat.com> CC: Philippe Mathieu-Daude <philmd@linaro.org> CC: mst@redhat.com CC: imammedo@redhat.com Signed-off-by: Ani Sinha <anisinha@redhat.com> Message-ID: <20230922124203.127110-1-anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> [Commit message tweaked] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2023-09-21hw/other: spelling fixesMichael Tokarev1-1/+1
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2023-07-10hw/smbios: Fix core count in type4Zhao Liu1-2/+4
>From SMBIOS 3.0 specification, core count field means: Core Count is the number of cores detected by the BIOS for this processor socket. [1] Before 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology"), MachineState.smp.cores means "the number of cores in one package", and it's correct to use smp.cores for core count. But 003f230e37d7 changes the smp.cores' meaning to "the number of cores in one die" and doesn't change the original smp.cores' use in smbios as well, which makes core count in type4 go wrong. Fix this issue with the correct "cores per socket" caculation. [1] SMBIOS 3.0.0, section 7.5.6, Processor Information - Core Count Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-5-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/smbios: Fix thread count in type4Zhao Liu1-2/+5
>From SMBIOS 3.0 specification, thread count field means: Thread Count is the total number of threads detected by the BIOS for this processor socket. It is a processor-wide count, not a thread-per-core count. [1] So here we should use threads per socket other than threads per core. [1] SMBIOS 3.0.0, section 7.5.8, Processor Information - Thread Count Fixes: c97294ec1b9e ("SMBIOS: Build aggregate smbios tables and entry point") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-4-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-07-10hw/smbios: Fix smbios_smp_sockets caculationZhao Liu1-2/+1
smp.sockets is the number of sockets which is configured by "-smp" ( otherwise, the default is 1). Trying to recalculate it here with another rules leads to errors, such as: 1. 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") changes the meaning of smp.cores but doesn't fix original smp.cores uses. With the introduction of cluster, now smp.cores means the number of cores in one cluster. So smp.cores * smp.threads just means the threads in a cluster not in a socket. 2. On the other hand, we shouldn't use smp.cpus here because it indicates the initial number of online CPUs at the boot time, and is not mathematically related to smp.sockets. So stop reinventing the another wheel and use the topo values that has been calculated. Fixes: 003f230e37d7 ("machine: Tweak the order of topology members in struct CpuTopology") Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20230628135437.1145805-3-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-06-20meson: Replace softmmu_ss -> system_ssPhilippe Mathieu-Daudé1-3/+3
We use the user_ss[] array to hold the user emulation sources, and the softmmu_ss[] array to hold the system emulation ones. Hold the latter in the 'system_ss[]' array for parity with user emulation. Mechanical change doing: $ sed -i -e s/softmmu_ss/system_ss/g $(git grep -l softmmu_ss) Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230613133347.82210-10-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-03-02hw/smbios: fix field corruption in type 4 tableJulia Suvorova1-3/+5
Since table type 4 of SMBIOS version 2.6 is shorter than 3.0, the strings which follow immediately after the struct fields have been overwritten by unconditional filling of later fields such as core_count2. Make these fields dependent on the SMBIOS version. Fixes: 05e27d74c7 ("hw/smbios: add core_count2 to smbios table type 4") Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2169904 Signed-off-by: Julia Suvorova <jusual@redhat.com> Message-Id: <20230223125747.254914-1-jusual@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-02-23hw/smbios: Dumb down smbios_entry_add() stubMarkus Armbruster1-3/+1
The QERR_ macros are leftovers from the days of "rich" error objects. We've been trying to reduce their remaining use. smbios_entry_add() is only ever called on behalf of CLI option -smbios. Since qemu-options.hx sets @arch_mask to QEMU_ARCH_I386 | QEMU_ARCH_ARM, it is reachable only for these targets. Since they provide a real smbios_entry_add(), the stub is unreachable. There's no point in unreachable code keeping QERR_UNSUPPORTED alive. Dumb it down to g_assert_not_reached(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230207075115.1525-6-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Juan Quintela <quintela@redhat.com>
2023-01-08include/hw/pci: Split pci_device.h off pci.hMarkus Armbruster1-0/+1
PCIDeviceClass and PCIDevice are defined in pci.h. Many users of the header don't actually need them. Similar structs live in their own headers: PCIBusClass and PCIBus in pci_bus.h, PCIBridge in pci_bridge.h, PCIHostBridgeClass and PCIHostState in pci_host.h, PCIExpressHost in pcie_host.h, and PCIERootPortClass, PCIEPort, and PCIESlot in pcie_port.h. Move PCIDeviceClass and PCIDeviceClass to new pci_device.h, along with the code that needs them. Adjust include directives. This also enables the next commit. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221222100330.380143-6-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-11-07hw/smbios: add core_count2 to smbios table type 4Julia Suvorova2-5/+23
In order to use the increased number of cpus, we need to bring smbios tables in line with the SMBIOS 3.0 specification. This allows us to introduce core_count2 which acts as a duplicate of core_count if we have fewer cores than 256, and contains the actual core number per socket if we have more. core_enabled2 and thread_count2 fields work the same way. Signed-off-by: Julia Suvorova <jusual@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220731162141.178443-2-jusual@redhat.com> Message-Id: <20221011111731.101412-2-jusual@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-10-09hw/smbios: support for type 8 (port connector)Hal Martin1-0/+63
PATCH v1: add support for SMBIOS type 8 to qemu PATCH v2: incorporate patch v1 feedback and add smbios type=8 to qemu-options internal_reference: internal reference designator external_reference: external reference designator connector_type: hex value for port connector type (see SMBIOS 7.9.2) port_type: hex value for port type (see SMBIOS 7.9.3) After studying various vendor implementationsi (Dell, Lenovo, MSI), the value of internal connector type was hard-coded to 0x0 (None). Example usage: -smbios type=8,internal_reference=JUSB1,external_reference=USB1,connector_type=0x12,port_type=0x10 \ -smbios type=8,internal_reference=JAUD1,external_reference="Audio Jack",connector_type=0x1f,port_type=0x1d \ -smbios type=8,internal_reference=LAN,external_reference=Ethernet,connector_type=0x0b,port_type=0x1f \ -smbios type=8,internal_reference=PS2,external_reference=Mouse,connector_type=0x0f,port_type=0x0e \ -smbios type=8,internal_reference=PS2,external_reference=Keyboard,connector_type=0x0f,port_type=0x0d Signed-off-by: Hal Martin <hal.martin@gmail.com> Message-Id: <20220812135153.17859-1-hal.martin@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-09-18smbios: sanitize type from external type before checking have_fields_bitmapPaolo Bonzini1-6/+8
test_bit uses header->type as an offset; if the file incorrectly specifies a type greater than 127, smbios_entry_add will read and write garbage. To fix this, just pass the smbios data through, assuming the user knows what to do. Reported by Coverity as CID 1487255. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-03-06hw/smbios: Add table 4 parameter, "processor-id"Patrick Venture1-3/+16
This parameter is to be used in the processor_id entry in the type 4 table. This parameter is set as optional and if left will use the values from the CPU model. This enables hiding the host information from the guest and allowing AMD VMs to run pretending to be Intel for some userspace software concerns. Reviewed-by: Peter Foley <pefoley@google.com> Reviewed-by: Titus Rwantare <titusr@google.com> Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220125163118.1011809-1-venture@google.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-03-04hw/smbios: add assertion to ensure handles of tables 19 and 32 do not collideAni Sinha1-0/+6
Since change dcf359832eec02 ("hw/smbios: fix table memory corruption with large memory vms") we reserve additional space between handle numbers of tables 17 and 19 for large VMs. This may cause table 19 to collide with table 32 in their handle numbers for those large VMs. This change adds an assertion to ensure numbers do not collide. If they do, qemu crashes with useful debug information for taking additional steps. Signed-off-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220223143322.927136-8-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-03-04hw/smbios: fix overlapping table handle numbers with large memory vmsAni Sinha1-4/+15
The current smbios table implementation splits the main memory in 16 GiB (DIMM like) chunks. With the current smbios table assignment code, we can have only 512 such chunks before the 16 bit handle numbers in the header for tables 17 and 19 conflict. A guest with more than 8 TiB of memory will hit this limitation and would fail with the following assertion in isa-debugcon: ASSERT_EFI_ERROR (Status = Already started) ASSERT /builddir/build/BUILD/edk2-ca407c7246bf/OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c(125): !EFI_ERROR (Status) This change adds an additional offset between tables 17 and 19 handle numbers when configuring VMs larger than 8 TiB of memory. The value of the offset is calculated to be equal to the additional space required to be reserved in order to accomodate more DIMM entries without the table handles colliding. In normal cases where the VM memory is smaller or equal to 8 TiB, this offset value is 0. Hence in this case, no additional handle numbers are reserved and table handle values remain as before. Since smbios memory is not transmitted over the wire during migration, this change can break migration for large memory vms if the guest is in the middle of generating the tables during migration. However, in those situations, qemu generates invalid table handles anyway with or without this fix. Hence, we do not preserve the old bug by introducing compat knobs/machine types. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2023977 Signed-off-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220223143322.927136-7-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-03-04hw/smbios: code cleanup - use macro definitions for table header handlesAni Sinha1-12/+26
This is a minor cleanup. Using macro definitions makes the code more readable. It is at once clear which tables use which handle numbers in their header. It also makes it easy to calculate the gaps between the numbers and update them if needed. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20220223143322.927136-6-ani@anisinha.ca> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-01-07smbios: Rename SMBIOS_ENTRY_POINT_* enumsEduardo Habkost1-4/+4
Rename the enums to match the naming style used by QAPI, and to use "32" and "64" instead of "20" and "31". This will allow us to more easily move the enum to the QAPI schema later. About the naming choice: "SMBIOS 2.1 entry point"/"SMBIOS 3.0 entry point" and "32-bit entry point"/"64-bit entry point" are synonymous in the SMBIOS specification. However, the phrases "32-bit entry point" and "64-bit entry point" are used more often. The new names also avoid confusion between the entry point format and the actual SMBIOS version reported in the entry point structure. For example: currently the 32-bit entry point actually report SMBIOS 2.8 support, not 2.1. Based on portions of a patch submitted by Daniel P. Berrangé. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20211026151100.1691925-2-ehabkost@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-05-14hw/smbios: support for type 41 (onboard devices extended information)Vincent Bernat1-1/+123
Type 41 defines the attributes of devices that are onboard. The original intent was to imply the BIOS had some level of control over the enablement of the associated devices. If network devices are present in this table, by default, udev will name the corresponding interfaces enoX, X being the instance number. Without such information, udev will fallback to using the PCI ID and this usually gives ens3 or ens4. This can be a bit annoying as the name of the network card may depend on the order of options and may change if a new PCI device is added earlier on the commande line. Being able to provide SMBIOS type 41 entry ensure the name of the interface won't change and helps the user guess the right name without booting a first time. This can be invoked with: $QEMU -netdev user,id=internet -device virtio-net-pci,mac=50:54:00:00:00:42,netdev=internet,id=internet-dev \ -smbios type=41,designation='Onboard LAN',instance=1,kind=ethernet,pcidev=internet-dev The PCI segment is assumed to be 0. This should hold true for most cases. $ dmidecode -t 41 # dmidecode 3.3 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x2900, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard LAN Type: Ethernet Status: Enabled Type Instance: 1 Bus Address: 0000:00:09.0 $ ip -brief a lo UNKNOWN 127.0.0.1/8 ::1/128 eno1 UP 10.0.2.14/24 fec0::5254:ff:fe00:42/64 fe80::5254:ff:fe00:42/64 Signed-off-by: Vincent Bernat <vincent@bernat.ch> Message-Id: <20210401171138.62970-1-vincent@bernat.ch> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-12-10i386: do not use ram_size globalPaolo Bonzini1-4/+4
Use the loader parameters instead. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-11-03hw/smbios: Fix leaked fd in save_opt_one() error pathPhilippe Mathieu-Daudé1-1/+3
Fix the following Coverity issue (RESOURCE_LEAK): CID 1432879: Resource leak Handle variable fd going out of scope leaks the handle. Replace a close() call by qemu_close() since the handle is opened with qemu_open(). Fixes: bb99f4772f5 ("hw/smbios: support loading OEM strings values from a file") Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20201030152742.1553968-1-philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-29hw/smbios: report error if table size is too largeDaniel P. Berrangé1-0/+14
The SMBIOS 2.1 entry point uses a uint16 data type for reporting the total length of the tables. If the user passes -smbios configuration to QEMU that causes the table size to exceed this limit then various bad behaviours result, including - firmware hangs in an infinite loop - firmware triggers a KVM crash on bad memory access - firmware silently discards user's SMBIOS data replacing it with a generic data set. Limiting the size to 0xffff in QEMU avoids triggering most of these problems. There is a remaining bug in SeaBIOS which tries to prepend its own data for table 0, and does not check whether there is sufficient space before attempting this. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200923133804.2089190-3-berrange@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-29hw/smbios: support loading OEM strings values from a fileDaniel P. Berrangé1-13/+58
Some applications want to pass quite large values for the OEM strings entries. Rather than having huge strings on the command line, it would be better to load them from a file, as supported with -fw_cfg. This introduces the "path" parameter allowing for: $ echo -n "thisthing" > mydata.txt $ qemu-system-x86_64 \ -smbios type=11,value=something \ -smbios type=11,path=mydata.txt \ -smbios type=11,value=somemore \ ...other args... Now in the guest $ dmidecode -t 11 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x0E00, DMI type 11, 5 bytes OEM Strings String 1: something String 2: thisthing String 3: somemore Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200923133804.2089190-2-berrange@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-08-27hw/smbios: add options for type 4 max-speed and current-speedYing Fang1-4/+32
Common VM users sometimes care about CPU speed, so we add two new options to allow VM vendors to present CPU speed to their users. Normally these information can be fetched from host smbios. Strictly speaking, the "max speed" and "current speed" in type 4 are not really for the max speed and current speed of processor, for "max speed" identifies a capability of the system, and "current speed" identifies the processor's speed at boot (see smbios spec), but some applications do not tell the differences. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Ying Fang <fangying1@huawei.com> Signed-off-by: Heyi Guo <guoheyi@huawei.com> Message-Id: <20200806035634.376-2-fangying1@huawei.com>
2020-08-21meson: convert hw/smbiosMarc-André Lureau2-10/+13
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-10error: Eliminate error_propagate() with Coccinelle, part 1Markus Armbruster1-17/+8
When all we do with an Error we receive into a local variable is propagating to somewhere else, we can just as well receive it there right away. Convert if (!foo(..., &err)) { ... error_propagate(errp, err); ... return ... } to if (!foo(..., errp)) { ... ... return ... } where nothing else needs @err. Coccinelle script: @rule1 forall@ identifier fun, err, errp, lbl; expression list args, args2; binary operator op; constant c1, c2; symbol false; @@ if ( ( - fun(args, &err, args2) + fun(args, errp, args2) | - !fun(args, &err, args2) + !fun(args, errp, args2) | - fun(args, &err, args2) op c1 + fun(args, errp, args2) op c1 ) ) { ... when != err when != lbl: when strict - error_propagate(errp, err); ... when != err ( return; | return c2; | return false; ) } @rule2 forall@ identifier fun, err, errp, lbl; expression list args, args2; expression var; binary operator op; constant c1, c2; symbol false; @@ - var = fun(args, &err, args2); + var = fun(args, errp, args2); ... when != err if ( ( var | !var | var op c1 ) ) { ... when != err when != lbl: when strict - error_propagate(errp, err); ... when != err ( return; | return c2; | return false; | return var; ) } @depends on rule1 || rule2@ identifier err; @@ - Error *err = NULL; ... when != err Not exactly elegant, I'm afraid. The "when != lbl:" is necessary to avoid transforming if (fun(args, &err)) { goto out } ... out: error_propagate(errp, err); even though other paths to label out still need the error_propagate(). For an actual example, see sclp_realize(). Without the "when strict", Coccinelle transforms vfio_msix_setup(), incorrectly. I don't know what exactly "when strict" does, only that it helps here. The match of return is narrower than what I want, but I can't figure out how to express "return where the operand doesn't use @err". For an example where it's too narrow, see vfio_intx_enable(). Silently fails to convert hw/arm/armsse.c, because Coccinelle gets confused by ARMSSE being used both as typedef and function-like macro there. Converted manually. Line breaks tidied up manually. One nested declaration of @local_err deleted manually. Preexisting unwanted blank line dropped in hw/riscv/sifive_e.c. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200707160613.848843-35-armbru@redhat.com>
generated by cgit v1.1 at 2024-07-21 13:30:31 +0000