aboutsummaryrefslogtreecommitdiffstats
path: root/src/fw
Commit message (Collapse)AuthorAgeFilesLines
* limit address space used for pci devices, part twoGerd Hoffmann2024-06-241-5/+10
| | | | | | | | | | | | | | This patch changes the logic added by commit a6ed6b701f0a ("limit address space used for pci devices.") a bit. Further testing showed that the limit of 46 phys-bits applies to x86_64 kernels only, for i386 kernels the limit is 44. So change the limit from 46 to 44 for better compatibility with i386 guests. Also add one more condition to refine the configuration heuristic: Apply the limit only in case the guest has less than 1 TB of memory installed, so huge guests run without address space limits. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* pciinit: don't misalign large BARsDaniil Tatianin2024-04-151-2/+4
| | | | | | | | | | | | | | | | | | | | Previously we would unconditionally lower the alignment for large BARs in case their alignment was greater than "pci_mem64_top >> 11", this would make it impossible to use these devices by the kernel: [ 13.821108] pci 0000:9c:00.0: can't claim BAR 1 [mem 0x66000000000-0x67fffffffff 64bit pref]: no compatible bridge window [ 13.823492] pci 0000:9d:00.0: can't claim BAR 1 [mem 0x64000000000-0x65fffffffff 64bit pref]: no compatible bridge window [ 13.824218] pci 0000:9e:00.0: can't claim BAR 1 [mem 0x62000000000-0x63fffffffff 64bit pref]: no compatible bridge window [ 13.828322] pci 0000:8a:00.0: can't claim BAR 1 [mem 0x6e000000000-0x6ffffffffff 64bit pref]: no compatible bridge window [ 13.830691] pci 0000:8b:00.0: can't claim BAR 1 [mem 0x6c000000000-0x6dfffffffff 64bit pref]: no compatible bridge window [ 13.832218] pci 0000:8c:00.0: can't claim BAR 1 [mem 0x6a000000000-0x6bfffffffff 64bit pref]: no compatible bridge window Fix it by only overwriting the alignment in case it's actually greater than the desired by the BAR window. Fixes: 96a8d130a8c ("be less conservative with the 64bit pci io window") Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
* fix smbios blob length overflowIgor Mammedov2024-03-031-1/+1
| | | | | | | | | | | | | When tables are more than 64K, size of copied tables will be truncated due to cast from u32 to u16, and as result only a small portion of the tables will be copied in the end. That leads to corrupted tables (a part from QEMU and remainder is whatever was in memory block allocated for the tables). Fix it by making qtables_len 32bit int. Signed-off-by: Igor Mammedov <imammedo@redhat.com>
* limit address space used for pci devices.Gerd Hoffmann2023-11-131-12/+26
| | | | | | | | | | | | | | | For better compatibility with old linux kernels, see source code comment. Also rename some variables to make the code more readable, following suggestions by Kevin. Related (same problem in ovmf): https://github.com/tianocore/edk2/commit/c1e853769046 Cc: Kevin O'Connor <kevin@koconnor.net> Reported-by: Claudio Fontana <cfontana@suse.de> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* check for e820 conflictGerd Hoffmann2023-08-241-0/+2
| | | | | | | | | | | Add support to check for overlaps with e820 entries. In case the 64bit pci io window has conflicts move it down. The only known case where this happens is AMD processors with 1TB address space which has some space just below 1TB reserved for HT. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* qemu: log reservations in fw_cfg e820 tableGerd Hoffmann2023-08-241-1/+1
| | | | | | | With loglevel 1 (same we use for RAM entries), so it is included in the firmware log by default. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* be less conservative with the 64bit pci io windowGerd Hoffmann2023-08-241-4/+12
| | | | | | | | | | | | | | | | | | | | | Current seabios code will only enable and use the 64bit pci io window in case it runs out of space in the 32bit pci mmio window below 4G. This patch will also enable the 64bit pci io window when (a) RAM above 4G is present, and (b) the physical address space size is known, and (c) seabios is running on a 64bit capable processor. This operates with the assumption that guests which are ok with memory above 4G most likely can handle mmio above 4G too. In case the 64bit pci io window is enabled also assign more memory to prefetchable pci bridge windows and the complete 64bit pci io window. The total mmio window size is 1/8 of the physical address space. Minimum bridge windows size is 1/256 of the total mmio window size. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* move 64bit pci window to end of address spaceGerd Hoffmann2023-08-241-0/+8
| | | | | | | When the size of the physical address space is known (PhysBits is not zero) move the 64bit pci io window to the end of the address space. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* detect physical address space sizeGerd Hoffmann2023-08-242-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | Check for pae and long mode using cpuid. If present also read the physical address bits. Apply some qemu sanity checks (see below). Record results in PhysBits and LongMode variables. In case we are not sure what the address space size is leave the PhysBits variable unset. On qemu we have the problem that for historical reasons x86_64 processors advertise 40 physical address space bits by default, even in case the host supports less than that so actually using the whole address space will not work. Because of that the code applies some extra sanity checks in case we find 40 (or less) physical address space bits advertised. Only known-good values (which is 40 for amd processors and 36+39 for intel processors) will be accepted as valid. Recommendation is to use 'qemu -cpu ${name},host-phys-bits=on' to advertise valid physical address space bits to the guest. Some distro builds enable this by default, and most likely the qemu default will change in near future too. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* better kvm detectionGerd Hoffmann2023-08-241-9/+21
| | | | | | | | | | | In case kvm emulates features of another hypervisor (for example hyperv) two VMM CPUID blocks will be present, one for the emulated hypervisor and one for kvm itself. This patch makes seabios loop over the VMM CPUID blocks to make sure it will properly detect kvm when multiple blocks are present. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* Fix high memory zone initialization in CSM modeJosé Martínez2023-06-131-2/+2
| | | | | | | | | | | | | malloc_high() cannot allocate any memory in CSM mode due to an empty ZoneHigh. SeaBIOS cannot find any disk to boot from because device initialization fails. The bug was introduced in 1.16.1 (commit dc88f9b) when the meaning of BUILD_MAX_HIGHTABLE changed but CSM code was not updated. This patch reverts to the previous behavior by using BUILD_MIN_HIGHTABLE in CSM methods. Signed-off-by: José Martínez <xose@google.com>
* xen: require Xen info structure at 0x1000 to detect XenDavid Woodhouse2023-02-011-13/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running under Xen, hvmloader places a table at 0x1000 with the e820 information and BIOS tables. If this isn't present, SeaBIOS will currently panic. We now have support for running Xen guests natively in QEMU/KVM, which boots SeaBIOS directly instead of via hvmloader, and does not provide the same structure. As it happens, this doesn't matter on first boot. because although we set PlatformRunningOn to PF_QEMU|PF_XEN, reading it back again still gives zero. Presumably because in true Xen, this is all already RAM. But in QEMU with a faithfully-emulated PAM config in the host bridge, it's still in ROM mode at this point so we don't see what we've just written. On reboot, however, the region *is* set to RAM mode and we do see the updated value of PlatformRunningOn, do manage to remember that we've detected Xen in CPUID, and hit the panic. It's not trivial to detect QEMU vs. real Xen at the time xen_preinit() runs, because it's so early. We can't even make a XENVER_extraversion hypercall to look for hints, because we haven't set up the hypercall page (and don't have an allocator to give us a page in which to do so). So just make Xen detection contingent on the info structure being present. If it wasn't, we were going to panic anyway. That leaves us taking the standard QEMU init path for Xen guests in native QEMU, which is just fine. Untested on actual Xen but ObviouslyCorrect™. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
* acpi: parse Alias objectIgor Mammedov2022-11-231-0/+4
| | | | | | | | | | | | | | | | | | | Since QEMU commit 47a373faa6 (acpi: pc/q35: drop ad-hoc PCI-ISA bridge AML routines and let bus ennumeration generate AML) SeaBIOS fails to parse ISA bridge AML with: parse_termlist: parse error, skip from 92/517 ... ACPI: no PS/2 keyboard present due to Alias term in DSDT which isn't handled by SeaBIOS properly. Add dumb Alias parsing which just skips over term, so the rest of AML could be parsed successfully. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reported-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20221118142755.3879231-1-imammedo@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* reset: force standard PCI configuration accessVolker Rümelin2022-04-041-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | After a reset of a QEMU -machine q35 guest, the PCI Express Enhanced Configuration Mechanism is disabled and the variable mmconfig no longer matches the configuration register PCIEXBAR of the Q35 chipset. Until the variable mmconfig is reset to 0, all pci_config_*() functions no longer work. The variable mmconfig is located in one of the read-only C-F segments. To reset it the pci_config_*() functions are needed, but they do not work. Replace all pci_config_*() calls with Standard PCI Configuration Mechanism pci_ioconfig_*() calls until mmconfig is overwritten with 0 by a fresh copy of the BIOS. This fixes In resume (status=0) In 32bit resume Attempting a hard reboot Unable to unlock ram - bridge not found and a reset loop with QEMU -accel tcg. Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
* smm: Suppress gcc array-bounds warningsKevin O'Connor2022-01-211-6/+15
| | | | | | | | Add a hack to suppress spurious gcc array-bounds warning (on at least gcc v11). Signed-off-by: Kevin O'Connor <kevin@koconnor.net> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
* pci: let firmware reserve IO for pcie-pci-bridgeIgor Mammedov2021-12-181-5/+14
| | | | | | | | | | | | | | | | | | | | | | With [1] patch hotplug of rtl8139 succeeds, with caveat that it fails to initialize IO bar, which is caused by [2] that makes firmware skip IO reservation for any PCIe device, which isn't correct in case of pcie-pci-bridge. Fix it by exposing hotplug type and making IO resource optional only if PCIe hotplug is in use. [1] "pci: reserve resources for pcie-pci-bridge to fix regressed hotplug on q35" [2] Fixes: 76327b9f32a ("fw/pci: do not automatically allocate IO region for PCIe bridges") Signed-off-by: Igor Mammedov imammedo@redhat.com Tested-by: Laurent Vivier <lvivier@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> CC: mapfelba@redhat.com CC: kraxel@redhat.com CC: mst@redhat.com CC: lvivier@redhat.com CC: jusual@redhat.com
* pci: reserve resources for pcie-pci-bridge to fix regressed hotplug on q35Igor Mammedov2021-12-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If QEMU is started with unpopulated pcie-pci-bridge with ACPI PCI hotplug enabled (default since QEMU-6.1), hotplugging a PCI device into one of the bridge slots fails due to lack of resources. once linux guest is booted (test used Fedora 34), hotplug NIC from QEMU monitor: (qemu) device_add rtl8139,bus=pcie-pci-bridge-0,addr=0x2 guest fails hotplug with: pci 0000:01:02.0: [10ec:8139] type 00 class 0x020000 pci 0000:01:02.0: reg 0x10: [io 0x0000-0x00ff] pci 0000:01:02.0: reg 0x14: [mem 0x00000000-0x000000ff] pci 0000:01:02.0: reg 0x30: [mem 0x00000000-0x0003ffff pref] pci 0000:01:02.0: BAR 6: no space for [mem size 0x00040000 pref] pci 0000:01:02.0: BAR 6: failed to assign [mem size 0x00040000 pref] pci 0000:01:02.0: BAR 0: no space for [io size 0x0100] pci 0000:01:02.0: BAR 0: failed to assign [io size 0x0100] pci 0000:01:02.0: BAR 1: no space for [mem size 0x00000100] pci 0000:01:02.0: BAR 1: failed to assign [mem size 0x00000100] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) PCI Interrupt Link [GSIG] enabled at IRQ 22 8139cp 0000:01:02.0: no MMIO resource 8139cp: probe of 0000:01:02.0 failed with error -5 Reason for this is that commit [1] didn't take into account pcie-pci-bridge, marking bridge as non hotpluggable instead of handling it as possibly SHPC capable bridge. Fix issue by checking if pcie-pci-bridge is SHPC capable and if it is mark it as hotpluggable. Fixes regression in QEMU-6.1 and later, since it was switched to ACPI based PCI hotplug on Q35 by default at that time. RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2001732 [1] Fixes: 3aa31d7d637 ("hw/pci: reserve IO and mem for pci express downstream ports with no devices attached") Signed-off-by: Igor Mammedov imammedo@redhat.com Acked-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Laurent Vivier <lvivier@redhat.com> CC: mapfelba@redhat.com CC: kraxel@redhat.com CC: mst@redhat.com CC: lvivier@redhat.com CC: jusual@redhat.com
* smbios: Support SMBIOS 3.0 entry point at smbios_romfile_setup()Eduardo Habkost2021-12-181-3/+30
| | | | | | Support SMBIOS 3.0 entry points if exposed by QEMU in fw_cfg. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Support SMBIOS 3.0 entry point at copy_table()Eduardo Habkost2021-12-181-0/+1
| | | | | | | | This will make coreboot code (scan_tables()) and xen code (xen_biostable_setup()) copy SMBIOS 3.0 entry points if found. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: copy_smbios_30() functionEduardo Habkost2021-12-181-2/+34
| | | | | | | | | | | | | | | Add new copy_smbios_30() function, that will be used to support SMBIOS 3.0 entry points. The SMBIOS 3.0 entry point will be tracked in a separate SMBios30Addr variable, because both 2.1 and 3.0 entry points may exist at the same time. Adjust the smbios_get_tables(), smbios_major_version(), and smbios_minor_version() helpers to use the SMBIOS 3.0 entry point if available. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Make smbios_build_tables() ready for 64-bit tablesEduardo Habkost2021-12-181-3/+13
| | | | | | | | | Make smbios_build_tables() get u64 address and u32 length arguments, making it usable for SMBIOS 3.0. Adapt smbios_21_setup_entry_point() to use intermediate variables when calling smbios_build_tables(). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Make some smbios_build_tables() arguments optionalEduardo Habkost2021-12-181-2/+6
| | | | | | | Make max_structure_size and number_of_structures optional, as we don't have those fields in SMBIOS 3.0 entry points. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: smbios_21_setup_entry_point() functionEduardo Habkost2021-12-181-13/+20
| | | | | | | | Extract the code specific for building the SMBIOS 2.1 entry point from smbios_romfile_setup() to a new smbios_21_setup_entry_point() function. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Make smbios_build_tables() more genericEduardo Habkost2021-12-181-13/+19
| | | | | | | | | Instead of taking a SMBIOS 2.1 entry point as argument, make smbios_build_tables() take pointers to the fields it actually changes. This will allow us to reuse the function for SMBIOS 3.0 later. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Extract SMBIOS table building code to separate functionEduardo Habkost2021-12-181-20/+34
| | | | | | | | | | | | Move the code that builds the SMBIOS tables to a separate smbios_build_tables() function, to keep it isolated from the code that initializes the SMBIOS entry point. Thew new function will still take a smbios_21_entry_point argument to make code review easier, but this will be changed by the next commits. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Use smbios_next() at smbios_romfile_setup()Eduardo Habkost2021-12-181-3/+4
| | | | | | | | | | | Use smbios_next() instead of smbios_21_next(), to make the code more generic and reusable for SMBIOS 3.0 support. Note that `qtables_len` is initialized to `ftables->size` instead of `ep.structure_table_length` now, but both fields are guaranteed to have exactly the same value. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Make SMBios21Addr variable staticEduardo Habkost2021-12-181-1/+1
| | | | | | | The variable is now only used inside biostables.c, there's no need to make it global. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* csm: Don't check SMBios21Addr before calling copy_smbios_21()Eduardo Habkost2021-12-181-1/+1
| | | | | | | copy_smbios_21() already checks if SMBios21Addr is NULL, there's no need to check it before calling the function. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: smbios_major_version()/smbios_minor_version() helpersEduardo Habkost2021-12-181-3/+21
| | | | | | | They new helpers will be useful when we start supporting SMBIOS 3.0 entry points. Use the new helpers at display_uuid(). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Use smbios_get_tables()/smbios_next() at display_uuid()Eduardo Habkost2021-12-181-2/+4
| | | | | | | Make the code more generic, and not specific for SMBIOS 2.1 entry points. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: smbios_get_tables() functionEduardo Habkost2021-12-181-0/+9
| | | | | | | The new function will be useful for code that just needs the address and length of SMBIOS tables. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Generic smbios_next() functionEduardo Habkost2021-12-181-4/+12
| | | | | | | Extract generic code from smbios_21_next(), so it can be reused for SMBIOS 3.0 support. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* smbios: Rename code specific for SMBIOS 2.1 entry pointsEduardo Habkost2021-12-183-27/+27
| | | | | | | | Rename copy_smbios(), smbios_next(), SMBIOS_SIGNATURE, smbios_entry_point, and SMBiosAddr, to indicate they refer to SMBIOS 2.1 entry points. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* biostables: copy_fseg_table() functionEduardo Habkost2021-12-181-24/+16
| | | | | | | Replace the common malloc_fseg() + memcpy() code pattern with a helper function. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* dsdt: add support for pnp ids as stringsGerd Hoffmann2020-10-131-8/+13
| | | | | | | | | | | | | | | | PNP devices can be declared using eisaid encoding ... Name (_HID, EisaId ("PNP0103")) ... or as string ... Name (_HID, "PNP0A06") .. so lets support both variants. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200930111222.6020-3-kraxel@redhat.com
* smbios: avoid integer overflow when adding SMBIOS type 0 tableDaniel P. Berrangé2020-09-081-4/+10
| | | | | | | | | SeaBIOS implements the SMBIOS 2.1 entry point which is limited to a maximum length of 0xffff. If the SMBIOS data received from QEMU is large enough, then adding the type 0 table will cause integer overflow. This results in fun behaviour such as KVM crash, or hangs in SeaBIOS. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* acpi: find and register virtio-mmio devicesGerd Hoffmann2020-05-151-0/+2
| | | | | | | Seach for virtio-mmio devices in the DSDT table, register the devices found. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* acpi: add dsdt parserGerd Hoffmann2020-05-153-2/+672
| | | | | | | | Create a list of devices found in the DSDT table. Add helper functions to find devices, walk the list and figure device informations like mmio ranges and irqs. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* acpi: add xsdt supportGerd Hoffmann2020-05-151-10/+30
| | | | | | | In case a xsdt table is present (and located below 4G) prefer it over rsdt. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* qemu: check rtc presence before reading cpu count from cmosGerd Hoffmann2020-05-151-3/+10
| | | | | | | | | Read month register which should never have a value larger than 12. In case the read returns 0xff assume the rtc isn't there. Don't try to read the cpu count from cmos without rtc. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* qemu: rework e820 detectionGerd Hoffmann2020-05-151-51/+82
| | | | | | | | | Read e820 table from fw_cfg early. This avoids reading the cmos for ram detection on modern qemu. It also simplifies the ram detection logic. We stop doing ram detecion in two steps, so we don't have to worry about the second step overwriting the setup done by the first step. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* qemu: factor out qemu_cfg_detect()Gerd Hoffmann2020-05-151-4/+14
| | | | | | | Move qemu fw_cfg detection to separate function. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* pci: add mmconfig supportGerd Hoffmann2020-03-271-0/+1
| | | | | | | | | | Add support for pci config space access via mmconfig bar. Enable for qemu q35 chipset. Main advantage is that we need only one instead of two io operations per config space access, which translates to one instead of two vmexits for virtualization. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200323145911.22319-3-kraxel@redhat.com
* kvm: add support for reading tsc frequency from kvmclockGerd Hoffmann2020-03-162-0/+56
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200310102248.28412-4-kraxel@redhat.com
* kvm: add support for reading tsc frequency via cpuid.Gerd Hoffmann2020-03-161-0/+5
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200310102248.28412-3-kraxel@redhat.com
* kvm: detect unconditionallyGerd Hoffmann2020-03-161-7/+1
| | | | | | | | So we detect kvm even in case there is no qemu pci hostbridge present, for example when using the new, pci-less microvm machine type. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200310102248.28412-2-kraxel@redhat.com
* csm: Fix boot priority translationDavid Woodhouse2019-06-281-3/+20
| | | | | | | | | | Explicitly handle the BBS_DO_NOT_BOOT_FROM and BBS_IGNORE_ENTRY values. Also add one to the other priority values, as find_prio() does for entries from bootorder. SeaBIOS uses zero for an item explicitly selected in interactive_bootmenu(). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* csm: Sanitise alignment constraint in Legacy16GetTableAddressDavid Woodhouse2019-06-181-2/+12
| | | | | | | | | | | | The alignment constraint is defined in the CSM specifications as "Bit mapped. First non-zero bit from the right is the alignment." Use __fls() to sanitise the alignment given that definition, since passing a non-power-of-two alignment to _malloc() isn't going to work well. And cope with being passed zero, which was happening for the E820 table allocation from EDK2. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* pciinit: Use %pP shorthand for printing device ids in intel_igd_setup()Kevin O'Connor2019-05-231-12/+9
| | | | | | | | The hardcoded device names can cause false-positives on Windows bios version checks. Use the %pP format to avoid that. Reported-by: Sam Eiderman <shmuel.eiderman@oracle.com> Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
* smbios: Add missing zero byte to Type 0Sam Eiderman2019-05-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to SMBIOS Specification, section 6.1.3 Text Strings: "Text strings associated with a given SMBIOS structure are returned in the dmiStructBuffer, appended directly after the formatted portion of the structure. This method of returning string information eliminates the need for application software to deal with pointers embedded in the SMBIOS structure. Each string is terminated with a null (00h) BYTE and the set of strings is terminated with an additional null (00h) BYTE” Furthermore: "If the formatted portion of the structure contains string-reference fields and all the string fields are set to 0 (no string references), the formatted section of the structure is followed by two null (00h) BYTES" From the above it can be seen that any SMBIOS type which contains string references should end with an additional zero byte. This is currently handled in all SMBIOS types which use load_str_field_with_default() besides type0. Therefore, add the missing zero byte to SMBIOS Type 0. Running QEMU with: -machine pc-i440fx-2.0 (for legacy smbios) -smbios type=0,vendor=,version=,date= (for zero str_index) Will cause SMBIOS type0 entry to overrun type1 entry. Reviewed-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Ross Philipson <ross.philipson@oracle.com> Reviewed-By: Liran Alon <liran.alon@oracle.com> Signed-off-by: Sam Eiderman <shmuel.eiderman@oracle.com>
generated by cgit (git 2.34.1) at 2025-02-23 10:52:03 +0000