aboutsummaryrefslogtreecommitdiff
path: root/include/hw/nvram
AgeCommit message (Collapse)AuthorFilesLines
2024-12-20include: Rename sysemu/ -> system/Philippe Mathieu-Daudé3-3/+3
Headers in include/sysemu/ are not only related to system *emulation*, they are also used by virtualization. Rename as system/ which is clearer. Files renamed manually then mechanical change using sed tool. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Message-Id: <20241203172445.28576-1-philmd@linaro.org>
2024-12-14hw/nvram/fw_cfg: Remove fw_cfg_add_extra_pci_roots()Philippe Mathieu-Daudé1-9/+0
Now that all uses of fw_cfg_add_extra_pci_roots() have been converted to the newer pci_bus_add_fw_cfg_extra_pci_roots(), we can remove that bogus method. hw/nvram/fw_cfg must stay generic. Device specific entries have to be implemented using TYPE_FW_CFG_DATA_GENERATOR_INTERFACE. This mostly reverts commit 0abd38885ac0fcdb08653922f339849cad387961 ("fw_cfg: Refactor extra pci roots addition"). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20241206181352.6836-7-philmd@linaro.org>
2024-12-14hw/nvram/fw_cfg: Skip FW_CFG_DATA_GENERATOR when no data to generatePhilippe Mathieu-Daudé1-5/+8
Allow the FW_CFG_DATA_GENERATOR interface get_data() handler to return NULL when there is nothing to generate. In that case fw_cfg_add_file_from_generator() will not add any item and return %true. Reported-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20241213133352.10915-4-philmd@linaro.org>
2024-12-13hw/nvram/fw_cfg: Pass QOM parent to fw_cfg_add_file_from_generator()Philippe Mathieu-Daudé1-4/+6
Currently fw_cfg_add_file_from_generator() is restricted to command line created objects which reside in the '/objects' QOM container. In order to extend to other types of containers, pass the QOM parent by argument. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20241206181352.6836-3-philmd@linaro.org>
2024-12-13hw/nvram/fw_cfg: Rename fw_cfg_add_[file]_from_generator()Philippe Mathieu-Daudé1-3/+3
fw_cfg_add_from_generator() is adding a 'file' entry, so rename as fw_cfg_add_file_from_generator() for clarity. Besides, we might introduce generators for other entry types. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20241206181352.6836-2-philmd@linaro.org>
2024-10-03hw: Remove unused fw_cfg_init_ioDr. David Alan Gilbert1-1/+0
fw_cfg_init_io has been unused since 918a7f706b ("i386: load kernel on xen using DMA") Remove it. Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-20license: Update deprecated SPDX tag GPL-2.0+ to GPL-2.0-or-laterPhilippe Mathieu-Daudé1-1/+1
The 'GPL-2.0+' license identifier has been deprecated since license list version 2.0rc2 [1] and replaced by the 'GPL-2.0-or-later' [2] tag. [1] https://spdx.org/licenses/GPL-2.0+.html [2] https://spdx.org/licenses/GPL-2.0-or-later.html Mechanical patch running: $ sed -i -e s/GPL-2.0+/GPL-2.0-or-later/ \ $(git grep -lP 'SPDX-License-Identifier: \W+GPL-2.0\+[ $]' \ | egrep -v '^linux-headers|^include/standard-headers') Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-05hm/nvram/xlnx-versal-efuse-ctrl: Call register_finalize_blockPeter Maydell1-0/+1
The TYPE_XLNX_VERSAL_EFUSE_CTRL device creates a register block with register_init_block32() in its instance_init method; we must therefore destroy it in our instance_finalize method to avoid a leak in the QOM introspection "init-inspect-finalize" lifecycle: Direct leak of 304 byte(s) in 1 object(s) allocated from: #0 0x55f222b5b9d8 in __interceptor_calloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/qemu-system-aarch64+0x294e9d8) (BuildId: 420 43d49e1139e3f3071b1f22fac1e3e7249c9a6) #1 0x7fbb10669c50 in g_malloc0 debian/build/deb/../../../glib/gmem.c:161:13 #2 0x55f222f90c5d in register_init_block hw/core/register.c:248:34 #3 0x55f222f916be in register_init_block32 hw/core/register.c:299:12 #4 0x55f223bbdd15 in efuse_ctrl_init hw/nvram/xlnx-versal-efuse-ctrl.c:718:9 #5 0x55f225b23391 in object_init_with_type qom/object.c:420:9 #6 0x55f225b0a66b in object_initialize_with_type qom/object.c:562:5 #7 0x55f225b0bf0d in object_new_with_type qom/object.c:782:5 #8 0x55f225b0bfe1 in object_new qom/object.c:797:12 #9 0x55f226309e0d in qmp_device_list_properties qom/qom-qmp-cmds.c:144:11 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20240822162127.705879-7-peter.maydell@linaro.org
2024-09-05hw/nvram/xlnx-zynqmp-efuse: Call register_finalize_blockPeter Maydell1-0/+1
The TYPE_XLNX_ZYNQMP_EFUSE device creates a register block with register_init_block32() in its instance_init method; we must therefore destroy it in our instance_finalize method to avoid a leak in the QOM introspection "init-inspect-finalize" lifecycle: Direct leak of 304 byte(s) in 1 object(s) allocated from: #0 0x55f3ff5839d8 in __interceptor_calloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/qemu-system-aarch64+0x294d9d8) (BuildId: 23cf931c66865a71b6cc4da95156d03bc106fa72) #1 0x7f3f31c6bc50 in g_malloc0 debian/build/deb/../../../glib/gmem.c:161:13 #2 0x55f3ff9b8c5d in register_init_block hw/core/register.c:248:34 #3 0x55f3ff9b96be in register_init_block32 hw/core/register.c:299:12 #4 0x55f4005e5b25 in efuse_ctrl_init hw/nvram/xlnx-versal-efuse-ctrl.c:718:9 #5 0x55f40254afb1 in object_init_with_type qom/object.c:420:9 #6 0x55f40253228b in object_initialize_with_type qom/object.c:562:5 #7 0x55f402533b2d in object_new_with_type qom/object.c:782:5 #8 0x55f402533c01 in object_new qom/object.c:797:12 #9 0x55f402d31a2d in qmp_device_list_properties qom/qom-qmp-cmds.c:144:11 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20240822162127.705879-5-peter.maydell@linaro.org
2024-09-05hw/nvram/xlnx-bbram: Call register_finalize_blockPeter Maydell1-0/+1
The TYPE_XLNX_BBRAM device creates a register block with register_init_block32() in its instance_init method; we must therefore destroy it in our instance_finalize method to avoid a leak in the QOM introspection "init-inspect-finalize" lifecycle: Direct leak of 304 byte(s) in 1 object(s) allocated from: #0 0x5641518ca9d8 in __interceptor_calloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/qemu-system-aarch64+0x294d9d8) (BuildId: 4a6 18cb63d57d5a19ed45cfc262b08da47eaafe5) #1 0x7ff1aab31c50 in g_malloc0 debian/build/deb/../../../glib/gmem.c:161:13 #2 0x564151cffc5d in register_init_block hw/core/register.c:248:34 #3 0x564151d006be in register_init_block32 hw/core/register.c:299:12 #4 0x56415293df75 in bbram_ctrl_init hw/nvram/xlnx-bbram.c:462:9 #5 0x564154891dc1 in object_init_with_type qom/object.c:420:9 #6 0x56415487909b in object_initialize_with_type qom/object.c:562:5 #7 0x56415487a93d in object_new_with_type qom/object.c:782:5 #8 0x56415487aa11 in object_new qom/object.c:797:12 #9 0x56415507883d in qmp_device_list_properties qom/qom-qmp-cmds.c:144:11 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20240822162127.705879-4-peter.maydell@linaro.org
2024-07-01hw/nvram: Add BCM2835 OTP deviceRayhan Faizel1-0/+68
The OTP device registers are currently stubbed. For now, the device houses the OTP rows which will be accessed directly by other peripherals. Signed-off-by: Rayhan Faizel <rayhan.faizel@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-05-03fw_cfg: remove useless declarations from typedefs.hPaolo Bonzini1-0/+2
Only FWCfgState is used as part of APIs such as acpi_ghes_add_fw_cfg. Everything else need not be in typedefs.h. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-01-30acpi: Clean up includesPeter Maydell1-1/+0
This commit was created with scripts/clean-includes: ./scripts/clean-includes --git acpi include/hw/*/*acpi.h hw/*/*acpi.c All .c should include qemu/osdep.h first. The script performs three related cleanups: * Ensure .c files include qemu/osdep.h first. * Including it in a .h is redundant, since the .c already includes it. Drop such inclusions. * Likewise, including headers qemu/osdep.h includes is redundant. Drop these, too. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-10hw/arm/virt-acpi-build.c: Migrate fw_cfg creation to common locationSunil V L1-0/+15
RISC-V also needs to use the same code to create fw_cfg in DSDT. So, avoid code duplication by moving the code in arm and riscv to a device specific file. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-2-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-20hw: Replace anti-social QOM type names (again)Markus Armbruster3-4/+4
QOM type names containing ',' result in awful UI. We got rid of them in v6.0.0 (commit e178113ff64 hw: Replace anti-social QOM type names). A few have crept back since: xlnx,cframe-reg xlnx,efuse xlnx,pmc-efuse-cache xlnx,versal-cfu-apb xlnx,versal-cfu-fdro xlnx,versal-cfu-sfr xlnx,versal-crl xlnx,versal-efuse xlnx,zynqmp-efuse These are all device types. They can't be plugged with -device / device_add, except for "xlnx,efuse" (I'm not sure that one is intentional). They *can* be used with -device / device_add to request help. Usability is poor, though: you have to double the comma, like this: $ qemu-system-aarch64 -device xlnx,,pmc-efuse-cache,help They can also be used with -global, where you must *not* double the comma: $ qemu-system-aarch64 -global xlnx,efuse.drive-index=2 Trap for the unwary. "xlnx,efuse", "xlnx,versal-efuse", "xlnx,pmc-efuse-cache", "xlnx-zynqmp-efuse" are from v6.2.0, "xlnx,versal-crl" is from v7.1.0, and the remainder are new. Rename them all to "xlnx-FOO", like commit e178113ff64 did. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com> Message-ID: <20231117114457.177308-3-thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-19xlnx-bbram: hw/nvram: Use dot in device type nameTong Ho1-1/+1
This replaces the comma (,) to dot (.) in the device type name so the name can be used with the 'driver=' command line option. Signed-off-by: Tong Ho <tong.ho@amd.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Message-id: 20231003052139.199665-1-tong.ho@amd.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-08-31bulk: Do not declare function prototypes using 'extern' keywordPhilippe Mathieu-Daudé1-2/+2
By default, C function prototypes declared in headers are visible, so there is no need to declare them as 'extern' functions. Remove this redundancy in a single bulk commit; do not modify: - meson.build (used to check function availability at runtime) - pc-bios/ - libdecnumber/ - tests/ - *.c Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20230605175647.88395-5-philmd@linaro.org>
2023-03-02Revert "x86: return modified setup_data only if read as memory, not as file"Michael S. Tsirkin1-22/+0
This reverts commit e935b735085dfa61d8e6d276b6f9e7687796a3c7. Fixes: e935b73508 ("x86: return modified setup_data only if read as memory, not as file") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-03-02Revert "x86: don't let decompressed kernel image clobber setup_data"Michael S. Tsirkin1-9/+0
This reverts commit eac7a7791bb6d719233deed750034042318ffd56. Fixes: eac7a7791b ("x86: don't let decompressed kernel image clobber setup_data") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-02-07Merge tag 'pull-aspeed-20230207' of https://github.com/legoater/qemu into ↵Peter Maydell1-0/+39
staging aspeed queue: * various small cleanups and fixes * new variant of the supermicrox11-bmc machine using an ast2500-a1 SoC * at24c_eeprom extension to define eeprom contents with static arrays * ast10x0 model and test improvements * avocado update of images to use the latest # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmPiByEACgkQUaNDx8/7 # 7KF1nw/7BxVb8bxO5T00AnGDFNahDq3ItyisrbOkElDw18oN1eULrtZFH1UopjDE # 3HKwR2nb4X7MfcLirVXXxwO1GgIxUkeCsVEY6hpg3TxDPRhPW2toNpNt/WCfFKgq # ZdYdaKgkON/xHQPv6kgQzU2n9Zpuznj0CE9A3k1mAyBcCSitsvu4TW6AQBKmLgUR # 9lu61onfX9XoPxZv3abuY3c3UyzevOc6BUT67dmr8naAhHLyBU+DWAW6Kg0Dtc9j # p+bwxIDRimK50DJt9l13OLSAJyhrW1gMsPPGb+48OClpEOhHwq8oqRuMFpbHaQ0/ # 2MMtMbavXtzBScfmLzR3yw2IwohxSXKMe+7irkJiG/hc8/gtpRATaaS+zfvS0rla # QybWYtJyjmW+QUOnmBsKGwT0PWJcOd3bKtVPgPd7WGeHGVtTBOqU/svExaO+gIv8 # uX1gOelEgLmLenUjc/Wp4cHgnePTBK8vG1g3IrEtcCblhwpr0e3/aJgHGgO3cQzH # X9P2buwHyLzjsie9S1ebG9Ceg/VsGQpxNGISZdG+Z4c3+GYu5gcGQcqIAuFmwBnE # QHSNHJXITyWjo7UuqL7e1J7vROUKn0S15V9MO/yOmZgkqubu4Gt3jGcJtIGqIBlu # MFra7SiVjKBnt6PD3aKEdD9uahbqFUfmX9411ZmYUUzpfflKnCQ= # =IY/i # -----END PGP SIGNATURE----- # gpg: Signature made Tue 07 Feb 2023 08:09:05 GMT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-aspeed-20230207' of https://github.com/legoater/qemu: (25 commits) aspeed/sdmc: Drop unnecessary scu include tests/avocado: Test Aspeed Zephyr SDK v00.01.08 on AST1030 board hw/arm/aspeed_ast10x0: Add TODO comment to use Cortex-M4F hw/arm/aspeed_ast10x0: Map HACE peripheral hw/arm/aspeed_ast10x0: Map the secure SRAM hw/arm/aspeed_ast10x0: Map I3C peripheral hw/arm/aspeed_ast10x0: Add various unimplemented peripherals hw/misc/aspeed_hace: Do not crash if address_space_map() failed hw/watchdog/wdt_aspeed: Log unimplemented registers as UNIMP level hw/watchdog/wdt_aspeed: Extend MMIO range to cover more registers hw/watchdog/wdt_aspeed: Rename MMIO region size as 'iosize' hw/nvram/eeprom_at24c: Make reset behavior more like hardware hw/arm/aspeed: Add aspeed_eeprom.c hw/nvram/eeprom_at24c: Add init_rom field and at24c_eeprom_init_rom helper hw/arm/aspeed: Replace aspeed_eeprom_init with at24c_eeprom_init hw/arm: Extract at24c_eeprom_init helper from Aspeed and Nuvoton boards hw/core/loader: Remove declarations of option_rom_has_mr/rom_file_has_mr tests/avocado/machine_aspeed.py: Mask systemd services to speed up SDK boot tests/avocado/machine_aspeed.py: update buildroot tests m25p80: Add the is25wp256 SFPD table ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2023-02-07hw/nvram/eeprom_at24c: Add init_rom field and at24c_eeprom_init_rom helperPeter Delevoryas1-0/+16
Allows users to specify binary data to initialize an EEPROM, allowing users to emulate data programmed at manufacturing time. - Added init_rom and init_rom_size attributes to TYPE_AT24C_EE - Added at24c_eeprom_init_rom helper function to initialize attributes - If -drive property is provided, it overrides init_rom data Signed-off-by: Peter Delevoryas <peter@pjd.dev> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Ninad Palsule <ninadpalsule@us.ibm.com> Link: https://lore.kernel.org/r/20230128060543.95582-4-peter@pjd.dev Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-02-07hw/arm: Extract at24c_eeprom_init helper from Aspeed and Nuvoton boardsPeter Delevoryas1-0/+23
This helper is useful in board initialization because lets users initialize and realize an EEPROM on an I2C bus with a single function call. Signed-off-by: Peter Delevoryas <peter@pjd.dev> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Corey Minyard <cminyard@mvista.com> Link: https://lore.kernel.org/r/20230128060543.95582-2-peter@pjd.dev Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-02-06mac_nvram: Add block backend to persist NVRAM contentsBALATON Zoltan1-0/+1
Add a way to set a backing store for the mac_nvram similar to what spapr_nvram or mac_via PRAM already does to allow to save its contents between runs. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <4b1605a9e484cc95f6e141f297487a070fd418ac.1675297286.git.balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2023-01-28x86: don't let decompressed kernel image clobber setup_dataJason A. Donenfeld1-0/+9
The setup_data links are appended to the compressed kernel image. Since the kernel image is typically loaded at 0x100000, setup_data lives at `0x100000 + compressed_size`, which does not get relocated during the kernel's boot process. The kernel typically decompresses the image starting at address 0x1000000 (note: there's one more zero there than the compressed image above). This usually is fine for most kernels. However, if the compressed image is actually quite large, then setup_data will live at a `0x100000 + compressed_size` that extends into the decompressed zone at 0x1000000. In other words, if compressed_size is larger than `0x1000000 - 0x100000`, then the decompression step will clobber setup_data, resulting in crashes. Visually, what happens now is that QEMU appends setup_data to the kernel image: kernel image setup_data |--------------------------||----------------| 0x100000 0x100000+l1 0x100000+l1+l2 The problem is that this decompresses to 0x1000000 (one more zero). So if l1 is > (0x1000000-0x100000), then this winds up looking like: kernel image setup_data |--------------------------||----------------| 0x100000 0x100000+l1 0x100000+l1+l2 d e c o m p r e s s e d k e r n e l |-------------------------------------------------------------| 0x1000000 0x1000000+l3 The decompressed kernel seemingly overwriting the compressed kernel image isn't a problem, because that gets relocated to a higher address early on in the boot process, at the end of startup_64. setup_data, however, stays in the same place, since those links are self referential and nothing fixes them up. So the decompressed kernel clobbers it. Fix this by appending setup_data to the cmdline blob rather than the kernel image blob, which remains at a lower address that won't get clobbered. This could have been done by overwriting the initrd blob instead, but that poses big difficulties, such as no longer being able to use memory mapped files for initrd, hurting performance, and, more importantly, the initrd address calculation is hard coded in qboot, and it always grows down rather than up, which means lots of brittle semantics would have to be changed around, incurring more complexity. In contrast, using cmdline is simple and doesn't interfere with anything. The microvm machine has a gross hack where it fiddles with fw_cfg data after the fact. So this hack is updated to account for this appending, by reserving some bytes. Fixup-by: Michael S. Tsirkin <mst@redhat.com> Cc: x86@kernel.org Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Message-Id: <20221230220725.618763-1-Jason@zx2c4.com> Message-ID: <20230128061015-mutt-send-email-mst@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Eric Biggers <ebiggers@google.com> Tested-by: Mathias Krause <minipli@grsecurity.net>
2022-10-31mac_nvram: Use NVRAM_SIZE constantBALATON Zoltan1-2/+1
The NVRAM_SIZE constant was defined but not used. Rename it to MACIO_NVRAM_SIZE to match the device model and use it where appropriate. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <5b53c70438dfb46837af8a094e753706b06c4ec6.1666957578.git.balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2022-10-31hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.hBALATON Zoltan1-0/+52
All that is left in mac.h now belongs to the nvram emulation so rename it accordingly and only include it where it is really used. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <b82449369f718c0e207fe8c332fab550fa0230c0.1666957578.git.balaton@eik.bme.hu> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2022-10-14hw/arm, loongarch: Move load_image_to_fw_cfg() to common locationSunil V L1-0/+21
load_image_to_fw_cfg() is duplicated by both arm and loongarch. The same function will be required by riscv too. So, it's time to refactor and move this function to a common path. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-Id: <20221004092351.18209-2-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-09-27x86: return modified setup_data only if read as memory, not as fileJason A. Donenfeld1-0/+22
If setup_data is being read into a specific memory location, then generally the setup_data address parameter is read first, so that the caller knows where to read it into. In that case, we should return setup_data containing the absolute addresses that are hard coded and determined a priori. This is the case when kernels are loaded by BIOS, for example. In contrast, when setup_data is read as a file, then we shouldn't modify setup_data, since the absolute address will be wrong by definition. This is the case when OVMF loads the image. This allows setup_data to be used like normal, without crashing when EFI tries to use it. (As a small development note, strangely, fw_cfg_add_file_callback() was exported but fw_cfg_add_bytes_callback() wasn't, so this makes that consistent.) Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Laurent Vivier <laurent@vivier.eu> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Richard Henderson <richard.henderson@linaro.org> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Message-Id: <20220921093134.2936487-1-Jason@zx2c4.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30hw/nvram: Introduce Xilinx battery-backed ramTong Ho1-0/+54
This device is present in Versal and ZynqMP product families to store a 256-bit encryption key. Co-authored-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Co-authored-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Signed-off-by: Tong Ho <tong.ho@xilinx.com> Message-id: 20210917052400.1249094-5-tong.ho@xilinx.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30hw/nvram: Introduce Xilinx ZynqMP eFuse deviceTong Ho1-0/+44
This implements the Xilinx ZynqMP eFuse, an one-time field-programmable non-volatile storage device. There is only one such device in the Xilinx ZynqMP product family. Co-authored-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Co-authored-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Signed-off-by: Tong Ho <tong.ho@xilinx.com> Message-id: 20210917052400.1249094-4-tong.ho@xilinx.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30hw/nvram: Introduce Xilinx Versal eFuse deviceTong Ho1-0/+68
This implements the Xilinx Versal eFuse, an one-time field-programmable non-volatile storage device. There is only one such device in the Xilinx Versal product family. This device has two separate mmio interfaces, a controller and a flatten readback. The controller provides interfaces for field-programming, configuration, control, and status. The flatten readback is a cache to provide a byte-accessible read-only interface to efficiently read efuse array. Co-authored-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Co-authored-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Signed-off-by: Tong Ho <tong.ho@xilinx.com> Message-id: 20210917052400.1249094-3-tong.ho@xilinx.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30hw/nvram: Introduce Xilinx eFuse QOMTong Ho1-0/+132
This introduces the QOM for Xilinx eFuse, an one-time field-programmable storage bit array. The actual mmio interface to the array varies by device families and will be provided in different change-sets. Co-authored-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Co-authored-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@xilinx.com> Signed-off-by: Tong Ho <tong.ho@xilinx.com> Message-id: 20210917052400.1249094-2-tong.ho@xilinx.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-12-08fw_cfg: Refactor extra pci roots additionJiahui Cen1-0/+9
Extract extra pci roots addition from pc machine, which could be used by other machines. In order to make uefi get the extra roots, it is necessary to write extra roots into fw_cfg. And only if the uefi knows there are extra roots, the config spaces of devices behind the root could be obtained. Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Message-Id: <20201119014841.7298-3-cenjiahui@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-09-18Use OBJECT_DECLARE_SIMPLE_TYPE when possibleEduardo Habkost2-9/+4
This converts existing DECLARE_INSTANCE_CHECKER usage to OBJECT_DECLARE_SIMPLE_TYPE when possible. $ ./scripts/codeconverter/converter.py -i \ --pattern=AddObjectDeclareSimpleType $(git grep -l '' -- '*.[ch]') Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Paul Durrant <paul@xen.org> Message-Id: <20200916182519.415636-6-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-14hw/nvram: NPCM7xx OTP device modelHavard Skinnemoen1-0/+79
This supports reading and writing OTP fuses and keys. Only fuse reading has been tested. Protection is not implemented. Reviewed-by: Avi Fishman <avi.fishman@nuvoton.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com> Message-id: 20200911052101.2602693-9-hskinnemoen@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-09-09Use DECLARE_*CHECKER* macrosEduardo Habkost2-9/+9
Generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]') Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-12-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-13-ehabkost@redhat.com> Message-Id: <20200831210740.126168-14-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-09-09Move QOM typedefs and add missing includesEduardo Habkost2-4/+8
Some typedefs and macros are defined after the type check macros. This makes it difficult to automatically replace their definitions with OBJECT_DECLARE_TYPE. Patch generated using: $ ./scripts/codeconverter/converter.py -i \ --pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]') which will split "typdef struct { ... } TypedefName" declarations. Followed by: $ ./scripts/codeconverter/converter.py -i --pattern=MoveSymbols \ $(git grep -l '' -- '*.[ch]') which will: - move the typedefs and #defines above the type check macros - add missing #include "qom/object.h" lines if necessary Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-9-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-10-ehabkost@redhat.com> Message-Id: <20200831210740.126168-11-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-08-14nvram: Exit QEMU if NVRAM cannot contain all -prom-env dataGreg Kurz1-1/+2
Since commit 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter"), pseries machines can pre-initialize the "system" partition in the NVRAM with the data passed to all -prom-env parameters on the QEMU command line. In this case it is assumed that all the data fits in 64 KiB, but the user can easily pass more and crash QEMU: $ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \ echo -n " -prom-env " ; printf "%0.sx" {1..1024}; \ done) # this requires ~128 Kib malloc(): corrupted top size Aborted (core dumped) This happens because we don't check if all the prom-env data fits in the NVRAM and chrp_nvram_set_var() happily memcpy() it passed the buffer. This crash affects basically all ppc/ppc64 machine types that use -prom-env: - pseries (all versions) - g3beige - mac99 and also sparc/sparc64 machine types: - LX - SPARCClassic - SPARCbook - SS-10 - SS-20 - SS-4 - SS-5 - SS-600MP - Voyager - sun4u - sun4v Add a max_len argument to chrp_nvram_create_system_partition() so that it can check the available size before writing to memory. Since NVRAM is populated at machine init, it seems reasonable to consider this error as fatal. So, instead of reporting an error when we detect that the NVRAM is too small and adapt all machine types to handle it, we simply exit QEMU in all cases. This is still better than crashing. If someone wants another behavior, I guess this can be reworked later. Tested with: $ yes q | \ (for arch in ppc ppc64 sparc sparc64; do \ echo == $arch ==; \ qemu=${arch}-softmmu/qemu-system-$arch; \ for mach in $($qemu -M help | awk '! /^Supported/ { print $1 }'); do \ echo $mach; \ $qemu -M $mach -monitor stdio -nodefaults -nographic \ $(for ((x=0;x<128;x++)); do \ echo -n " -prom-env " ; printf "%0.sx" {1..1024}; \ done) >/dev/null; \ done; echo; \ done) Without the patch, affected machine types cause QEMU to report some memory corruption and crash: malloc(): corrupted top size free(): invalid size *** stack smashing detected ***: terminated With the patch, QEMU prints the following message and exits: NVRAM is too small. Try to pass less data to -prom-env It seems that the conditions for the crash have always existed, but it affects pseries, the machine type I care for, since commit 61f20b9dc5b7 only. Fixes: 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter") RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1867739 Reported-by: John Snow <jsnow@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <159736033937.350502.12402444542194031035.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-07-21hw/nvram/fw_cfg: Let fw_cfg_add_from_generator() return boolean valuePhilippe Mathieu-Daudé1-1/+3
Commits b6d7e9b66f..a43770df5d simplified the error propagation. Similarly to commit 6fd5bef10b "qom: Make functions taking Error** return bool, not void", let fw_cfg_add_from_generator() return a boolean value, not void. This allow to simplify parse_fw_cfg() and fixes the error handling issue reported by Coverity (CID 1430396): In parse_fw_cfg(): Variable assigned once to a constant guards dead code. Local variable local_err is assigned only once, to a constant value, making it effectively constant throughout its scope. If this is not the intent, examine the logic to see if there is a missing assignment that would make local_err not remain constant. It's the call of fw_cfg_add_from_generator(): Error *local_err = NULL; fw_cfg_add_from_generator(fw_cfg, name, gen_id, errp); if (local_err) { error_propagate(errp, local_err); return -1; } return 0; If it fails, parse_fw_cfg() sets an error and returns 0, which is wrong. Harmless, because the only caller passes &error_fatal. Reported-by: Peter Maydell <peter.maydell@linaro.org> Fixes: Coverity CID 1430396: 'Constant' variable guards dead code (DEADCODE) Fixes: 6552d87c48 ("softmmu/vl: Let -fw_cfg option take a 'gen_id' argument") Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200721131911.27380-3-philmd@redhat.com>
2020-07-21hw/nvram/fw_cfg: Simplify fw_cfg_add_from_generator() error propagationPhilippe Mathieu-Daudé1-1/+3
Document FWCfgDataGeneratorClass::get_data() return NULL on error, and non-NULL on success. This allow us to simplify fw_cfg_add_from_generator(). Since we don't need a local variable to propagate the error, we can remove the ERRP_GUARD() macro. Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200721131911.27380-2-philmd@redhat.com>
2020-07-03hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interfacePhilippe Mathieu-Daudé1-0/+43
The FW_CFG_DATA_GENERATOR allows any object to produce blob of data consumable by the fw_cfg device. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200623172726.21040-3-philmd@redhat.com>
2020-04-13fw_cfg: Migrate ACPI table mr sizes separatelyShameer Kolothum1-0/+6
Any sub-page size update to ACPI MRs will be lost during migration, as we use aligned size in ram_load_precopy() -> qemu_ram_resize() path. This will result in inconsistency in FWCfgEntry sizes between source and destination. In order to avoid this, save and restore them separately during migration. Up until now, this problem may not be that relevant for x86 as both ACPI table and Linker MRs gets padded and aligned. Also at present, qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for unaligned size changes. But since we are going to fix the qemu_ram_resize() in the subsequent patch, the issue may become more serious especially for RSDP MR case. Moreover, the issue will soon become prominent in arm/virt as well where the MRs are not padded or aligned at all and eventually have acpi table changes as part of future additions like NVDIMM hot-add feature. Suggested-by: David Hildenbrand <david@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Acked-by: David Hildenbrand <david@redhat.com> Message-Id: <20200403101827.30664-3-shameerali.kolothum.thodi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-10-22fw_cfg: add "modify" functions for all typesSergio Lopez1-0/+42
This allows to alter the contents of an already added item. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2019-08-16include: Make headers more self-containedMarkus Armbruster1-0/+2
Back in 2016, we discussed[1] rules for headers, and these were generally liked: 1. Have a carefully curated header that's included everywhere first. We got that already thanks to Peter: osdep.h. 2. Headers should normally include everything they need beyond osdep.h. If exceptions are needed for some reason, they must be documented in the header. If all that's needed from a header is typedefs, put those into qemu/typedefs.h instead of including the header. 3. Cyclic inclusion is forbidden. This patch gets include/ closer to obeying 2. It's actually extracted from my "[RFC] Baby steps towards saner headers" series[2], which demonstrates a possible path towards checking 2 automatically. It passes the RFC test there. [1] Message-ID: <87h9g8j57d.fsf@blackfin.pond.sub.org> https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03345.html [2] Message-Id: <20190711122827.18970-1-armbru@redhat.com> https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg02715.html Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-2-armbru@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-05-23hw/nvram/fw_cfg: Add fw_cfg_arch_key_name()Philippe Mathieu-Daudé1-0/+14
Add fw_cfg_arch_key_name() which returns the name of an architecture-specific key. Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190422195020.1494-3-philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-02-01hw/nvram/nrf51_nvm: Add nRF51 non-volatile memoriesSteffen Görtz1-0/+64
The nRF51 contains three regions of non-volatile memory (NVM): - CODE (R/W): contains code - FICR (R): Factory information like code size, chip id etc. - UICR (R/W): Changeable configuration data. Lock bits, Code protection configuration, Bootloader address, Nordic SoftRadio configuration, Firmware configuration. Read and write access to the memories is managed by the Non-volatile memory controller. Memory schema: [ CPU ] -+- [ NVM, either FICR, UICR or CODE ] | | \- [ NVMC ] Signed-off-by: Steffen Görtz <contrib@steffen-goertz.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190201023357.22596-2-stefanha@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-08-23fw_cfg: import & use linux/qemu_fw_cfg.hMarc-André Lureau2-60/+3
Use kernel common header for fw_cfg. (unfortunately, optionrom.h must have its own define, since it's actually an assembler header) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20180817155910.5722-2-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2018-02-09Clean up includesMarkus Armbruster1-1/+0
Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes, with the change to target/s390x/gen-features.c manually reverted, and blank lines around deletions collapsed. Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180201111846.21846-3-armbru@redhat.com>
2017-10-15fw_cfg: add write callbackMarc-André Lureau1-0/+3
Reintroduce the write callback that was removed when write support was removed in commit 023e3148567ac898c7258138f8e86c3c2bb40d07. Contrary to the previous callback implementation, the write_cb callback is called whenever a write happened, so handlers must be ready to handle partial write as necessary. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-09-08fw_cfg: rename read callbackMarc-André Lureau1-3/+4
The callback is called on select. Furthermore, the next patch introduced a new callback, so rename the function type with a generic name. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.1 at 2025-02-02 07:53:15 +0000