aboutsummaryrefslogtreecommitdiff
path: root/include/hw/nvram
AgeCommit message (Collapse)Author
2023-02-07Merge tag 'pull-aspeed-20230207' of https://github.com/legoater/qemu into ↵Peter Maydell
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 Delevoryas
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 Delevoryas
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 Zoltan
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. Donenfeld
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 Zoltan
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 Zoltan
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 L
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. Donenfeld
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 Ho
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 Ho
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 Ho
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 Ho
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 Cen
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 Habkost
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 Skinnemoen
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 Habkost
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 Habkost
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 Kurz
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é
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é
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é
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 Kolothum
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 Lopez
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 Armbruster
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é
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örtz
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é Lureau
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 Armbruster
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é Lureau
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é Lureau
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>
2017-07-17fw_cfg: move QOM type defines and fw_cfg types into fw_cfg.hMark Cave-Ayland
By exposing FWCfgIoState and FWCfgMemState internals we allow the possibility for the internal MemoryRegion fields to be mapped by name for boards that wish to wire up the fw_cfg device themselves. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <1500025208-14827-4-git-send-email-mark.cave-ayland@ilande.co.uk> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-01-18fw-cfg: turn FW_CFG_FILE_SLOTS into a device propertyLaszlo Ersek
We'd like to raise the value of FW_CFG_FILE_SLOTS. Doing it naively could lead to problems with backward migration: a more recent QEMU (running an older machine type) would allow the guest, in fw_cfg_select(), to select a high key value that is unavailable in the same machine type implemented by the older (target) QEMU. On the target host, fw_cfg_data_read() for example could dereference nonexistent entries. As first step, size the FWCfgState.entries[*] and FWCfgState.entry_order arrays dynamically. All three array sizes will be influenced by the new field FWCfgState.file_slots (and matching device property). Make the following changes: - Replace the FW_CFG_FILE_SLOTS macro with FW_CFG_FILE_SLOTS_MIN (minimum count of fw_cfg file slots) in the header file. The value remains 0x10. - Replace all uses of FW_CFG_FILE_SLOTS with a helper function called fw_cfg_file_slots(), returning the new property. - Eliminate the macro FW_CFG_MAX_ENTRY, and replace all its uses with a helper function called fw_cfg_max_entry(). - In the MMIO- and IO-mapped realize functions both, allocate all three arrays dynamically, based on the new property. - The new property defaults to FW_CFG_FILE_SLOTS_MIN. This is going to be customized in the following patches. Cc: "Gabriel L. Somlo" <somlo@cmu.edu> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2017-01-18fw-cfg: support writeable blobsMichael S. Tsirkin
Useful to send guest data back to QEMU. Changes from Laszlo Ersek <lersek@redhat.com>: - rebase the patch from Michael Tsirkin's original postings at [1] and [2] to the following patches: - loader: Allow a custom AddressSpace when loading ROMs - loader: Add AddressSpace loading support to uImages - loader: fix handling of custom address spaces when adding ROM blobs - reject such writes immediately that would exceed the end of the array, rather than performing a partial write before setting the error bit: see the (len != dma.length) condition - document the write interface [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg04968.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg02735.html Cc: "Gabriel L. Somlo" <somlo@cmu.edu> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Michael Walle <michael@walle.cc> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: qemu-arm@nongnu.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2016-10-28nvram: Rename openbios_firmware_abi.h into sun_nvram.hThomas Huth
The header now only contains inline functions related to the Sun NVRAM, so the a name like sun_nvram.h seems to be more appropriate now. Signed-off-by: Thomas Huth <thuth@redhat.com> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28nvram: Move the remaining CHRP NVRAM related code to chrp_nvram.[ch]Thomas Huth
Everything that is related to CHRP NVRAM should rather reside in chrp_nvram.c / chrp_nvram.h instead of openbios_firmware_abi.h. Signed-off-by: Thomas Huth <thuth@redhat.com> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-10-28nvram: Introduce helper functions for CHRP "system" and "free space" partitionsThomas Huth
The "system partition" and "free space" partition layouts are defined by the CHRP and LoPAPR specification, and used by OpenBIOS and SLOF. We can re-use this code for other machines that use OpenBIOS and SLOF, too. So let's make this code independent from the MAC NVRAM environment and put it into two proper helper functions. Signed-off-by: Thomas Huth <thuth@redhat.com> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-07-14Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream-fwcfg' into ↵Peter Maydell
staging * Updated fw_cfg option ROM to include DMA support # gpg: Signature made Thu 14 Jul 2016 14:51:06 BST # gpg: using RSA key 0xBFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream-fwcfg: Add optionrom compatible with fw_cfg DMA version Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-14Add optionrom compatible with fw_cfg DMA versionMarc Marí
This optionrom is based on linuxboot.S. Signed-off-by: Marc Marí <markmb@redhat.com> Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Message-Id: <1464027093-24073-2-git-send-email-rjones@redhat.com> [Add -fno-toplevel-reorder, support clang without -m16. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-07-12Clean up header guards that don't match their file nameMarkus Armbruster
Header guard symbols should match their file name to make guard collisions less likely. Offenders found with scripts/clean-header-guards.pl -vn. Cleaned up with scripts/clean-header-guards.pl, followed by some renaming of new guard symbols picked by the script to better ones. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-04-07Sort the fw_cfg file listGerd Hoffmann
Entries are inserted in filename order instead of being appended to the end in case sorting is enabled. This will avoid any future issues of moving the file creation around, it doesn't matter what order they are created now, the will always be in filename order. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Added machine type handling for compatibility. This was a fairly complex change, this will preserve the order of fw_cfg for older versions no matter what order the firmware files actually come in. A list is kept of the correct legacy order and the entries will be inserted based upon their order in the list. Except that some entries are ordered (in a specific area of the list) based upon what order they appear on the command line. Special handling is added for those entries. Signed-off-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-03-22fw_cfg: Split fw_cfg_keys.h off fw_cfg.hMarkus Armbruster
Much of fw_cfg.h's contents is #ifndef NO_QEMU_PROTOS. This lets a few places include it without satisfying the dependencies of the suppressed code. If you somehow include it with NO_QEMU_PROTOS, any future includes are ignored. Unnecessarily unclean. Move the stuff not under NO_QEMU_PROTOS into its own header fw_cfg_keys.h, and include it as appropriate. Tidy up the moved code to please checkpatch. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-22Use scripts/clean-includes to drop redundant qemu/typedefs.hMarkus Armbruster
Re-run scripts/clean-includes to apply the previous commit's corrections and updates. Besides redundant qemu/typedefs.h, this only finds a redundant config-host.h include in ui/egl-helpers.c. No idea how that escaped the previous runs. Some manual whitespace trimming around dropped includes squashed in. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-08fw_cfg: expose control register size in fw_cfg.hGabriel L. Somlo
Expose the size of the control register (FW_CFG_CTL_SIZE) in fw_cfg.h. Add comment to fw_cfg_io_realize() pointing out that since the 8-bit data register is always subsumed by the 16-bit control register in the port I/O case, we use the control register width as the *total* width of the (classic, non-DMA) port I/O region reserved for the device. Cc: Marc Marí <markmb@redhat.com> Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marc Marí <markmb@redhat.com> Message-id: 1455906029-25565-2-git-send-email-somlo@cmu.edu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2016-02-23include: Clean up includesPeter Maydell
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. NB: If this commit breaks compilation for your out-of-tree patchseries or fork, then you need to make sure you add #include "qemu/osdep.h" to any new .c files that you have. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-12-15fw_cfg: remove offset argument from callback prototypeGabriel L. Somlo
Read callbacks are now only invoked at item selection, before any data is read. As such, the value of the offset argument passed to the callback will always be 0. Also, the two callback instances currently in use both leave their offset argument unused. This patch removes the offset argument from the fw_cfg read callback prototype, and from the currently available instances. The unused (write) callback prototype is also removed (write support was removed earlier, in commit 023e3148). Cc: Laszlo Ersek <lersek@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc Marí <markmb@redhat.com> Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1446733972-1602-4-git-send-email-somlo@cmu.edu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-12-15fw_cfg: amend callback behavior spec to once per selectGabriel L. Somlo
Currently, the fw_cfg internal API specifies that if an item was set up with a read callback, the callback must be run each time a byte is read from the item. This behavior is both wasteful (most items do not have a read callback set), and impractical for bulk transfers (e.g., DMA read). At the time of this writing, the only items configured with a callback are "/etc/table-loader", "/etc/acpi/tables", and "/etc/acpi/rsdp". They all share the same callback functions: virt_acpi_build_update() on ARM (in hw/arm/virt-acpi-build.c), and acpi_build_update() on i386 (in hw/i386/acpi.c). Both of these callbacks are one-shot (i.e. they return without doing anything at all after the first time they are invoked with a given build_state; since build_state is also shared across all three items mentioned above, the callback only ever runs *once*, the first time either of the listed items is read). This patch amends the specification for fw_cfg_add_file_callback() to state that any available read callback will only be invoked once each time the item is selected. This change has no practical effect on the current behavior of QEMU, and it enables us to significantly optimize the behavior of fw_cfg reads during guest firmware setup, eliminating a large amount of redundant callback checks and invocations. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc Marí <markmb@redhat.com> Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1446733972-1602-3-git-send-email-somlo@cmu.edu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-12-15fw_cfg: move internal function call docs to header fileGabriel L. Somlo
Move documentation for fw_cfg functions internal to qemufrom docs/specs/fw_cfg.txt to the fw_cfg.h header file, next to their prototype declarations, formatted as doc-comments. NOTE: Documentation for fw_cfg_add_callback() is completely dropped by this patch, as that function has been eliminated by commit 023e3148. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc Marí <markmb@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1446733972-1602-2-git-send-email-somlo@cmu.edu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-10-19Implement fw_cfg DMA interfaceMarc Marí
Based on the specifications on docs/specs/fw_cfg.txt This interface is an addon. The old interface can still be used as usual. Based on Gerd Hoffman's initial implementation. Signed-off-by: Marc Marí <markmb@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-06-10fw_cfg: remove support for guest-side data writesGabriel L. Somlo
From this point forward, any guest-side writes to the fw_cfg data register will be treated as no-ops. This patch also removes the unused host-side API function fw_cfg_add_callback(), which allowed the registration of a callback to be executed each time the guest completed a full overwrite of a given fw_cfg data item. Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-03 06:33:28 +0000