aboutsummaryrefslogtreecommitdiff
path: root/hw/nvram
AgeCommit message (Collapse)AuthorFilesLines
2023-02-07hw/nvram/eeprom_at24c: Make reset behavior more like hardwarePeter Delevoryas1-12/+10
EEPROM's are a form of non-volatile memory. After power-cycling an EEPROM, I would expect the I2C state machine to be reset to default values, but I wouldn't really expect the memory to change at all. The current implementation of the at24c EEPROM resets its internal memory on reset. This matches the specification in docs/devel/reset.rst: Cold reset is supported by every resettable object. In QEMU, it means we reset to the initial state corresponding to the start of QEMU; this might differ from what is a real hardware cold reset. It differs from other resets (like warm or bus resets) which may keep certain parts untouched. But differs from my intuition. For example, if someone writes some information to an EEPROM, then AC power cycles their board, they would expect the EEPROM to retain that information. It's very useful to be able to test things like this in QEMU as well, to verify software instrumentation like determining the cause of a reboot. Fixes: 5d8424dbd3e8 ("nvram: add AT24Cx i2c eeprom") Signed-off-by: Peter Delevoryas <peter@pjd.dev> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Corey Minyard <cminyard@mvista.com> Link: https://lore.kernel.org/r/20230128060543.95582-6-peter@pjd.dev Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-02-07hw/nvram/eeprom_at24c: Add init_rom field and at24c_eeprom_init_rom helperPeter Delevoryas1-5/+31
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/+12
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/+28
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-12-14qapi machine: Elide redundant has_FOO in generated CMarkus Armbruster1-1/+1
The has_FOO for pointer-valued FOO are redundant, except for arrays. They are also a nuisance to work with. Recent commit "qapi: Start to elide redundant has_FOO in generated C" provided the means to elide them step by step. This is the step for qapi/machine*.json. Said commit explains the transformation in more detail. The invariant violations mentioned there do not occur here. Cc: Eduardo Habkost <eduardo@habkost.net> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Yanan Wang <wangyanan55@huawei.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20221104160712.3005652-16-armbru@redhat.com>
2022-10-31hw/ppc/mac.h: Rename to include/hw/nvram/mac_nvram.hBALATON Zoltan1-1/+1
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-22Drop useless casts from g_malloc() & friends to pointerMarkus Armbruster1-1/+1
These memory allocation functions return void *, and casting to another pointer type is useless clutter. Drop these casts. If you really want another pointer type, consider g_new(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20220923120025.448759-3-armbru@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-10-14hw/arm, loongarch: Move load_image_to_fw_cfg() to common locationSunil V L1-0/+32
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-6/+6
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>
2022-07-12block: Change blk_{pread,pwrite}() param orderAlberto Faria4-9/+9
Swap 'buf' and 'bytes' around for consistency with blk_co_{pread,pwrite}(), and in preparation to implement these functions using generated_co_wrapper. Callers were updated using this Coccinelle script: @@ expression blk, offset, buf, bytes, flags; @@ - blk_pread(blk, offset, buf, bytes, flags) + blk_pread(blk, offset, bytes, buf, flags) @@ expression blk, offset, buf, bytes, flags; @@ - blk_pwrite(blk, offset, buf, bytes, flags) + blk_pwrite(blk, offset, bytes, buf, flags) It had no effect on hw/block/nand.c, presumably due to the #if, so that file was updated manually. Overly-long lines were then fixed by hand. Signed-off-by: Alberto Faria <afaria@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220705161527.1054072-4-afaria@redhat.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2022-07-12block: Add a 'flags' param to blk_pread()Alberto Faria4-4/+4
For consistency with other I/O functions, and in preparation to implement it using generated_co_wrapper. Callers were updated using this Coccinelle script: @@ expression blk, offset, buf, bytes; @@ - blk_pread(blk, offset, buf, bytes) + blk_pread(blk, offset, buf, bytes, 0) It had no effect on hw/block/nand.c, presumably due to the #if, so that file was updated manually. Overly-long lines were then fixed by hand. Signed-off-by: Alberto Faria <afaria@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220705161527.1054072-3-afaria@redhat.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2022-07-12block: Make blk_{pread,pwrite}() return 0 on successAlberto Faria2-11/+11
They currently return the value of their 'bytes' parameter on success. Make them return 0 instead, for consistency with other I/O functions and in preparation to implement them using generated_co_wrapper. This also makes it clear that short reads/writes are not possible. Signed-off-by: Alberto Faria <afaria@redhat.com> Message-Id: <20220705161527.1054072-2-afaria@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2022-06-30hw/i2c: add asynchronous sendKlaus Jensen1-0/+2
Add an asynchronous version of i2c_send() that requires the slave to explicitly acknowledge on the bus with i2c_ack(). The current master must use the new i2c_start_send_async() to indicate that it wants to do an asynchronous transfer. This allows the i2c core to check if the target slave supports this or not. This approach relies on adding a new enum i2c_event member, which is why a bunch of other devices needs changes in their event handling switches. Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Message-Id: <20220601210831.67259-5-its@irrelevant.dk> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220630045133.32251-6-me@pjd.dev> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-05-12machine: use QAPI struct for boot configurationPaolo Bonzini1-20/+7
As part of converting -boot to a property with a QAPI type, define the struct and use it throughout QEMU to access boot configuration. machine_boot_parse takes care of doing the QemuOpts->QAPI conversion by hand, for now. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220414165300.555321-2-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-06Remove qemu-common.h include from most unitsMarc-André Lureau1-1/+0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-33-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-06Replace qemu_real_host_page variables with inlined functionsMarc-André Lureau1-3/+3
Replace the global variables with inlined helper functions. getpagesize() is very likely annotated with a "const" function attribute (at least with glibc), and thus optimization should apply even better. This avoids the need for a constructor initialization too. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-12-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-05xlnx-bbram: hw/nvram: Fix uninitialized Error *Tong Ho1-1/+1
This adds required initialization of Error * variable. Signed-off-by: Tong Ho <tong.ho@xilinx.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-03-14hw/nvram: at24 return 0xff if 1 byte addressPatrick Venture1-1/+6
The at24 eeproms are 2 byte devices that return 0xff when they are read from with a partial (1-byte) address written. This distinction was found comparing model behavior to real hardware testing. Tested: `i2ctransfer -f -y 45 w1@85 0 r1` returns 0xff instead of next byte Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211220212137.1244511-1-venture@google.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2022-03-04block: rename bdrv_invalidate_cache_all, blk_invalidate_cache and ↵Emanuele Giuseppe Esposito1-1/+1
test_sync_op_invalidate_cache Following the bdrv_activate renaming, change also the name of the respective callers. bdrv_invalidate_cache_all -> bdrv_activate_all blk_invalidate_cache -> blk_activate test_sync_op_invalidate_cache -> test_sync_op_activate No functional change intended. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220209105452.1694545-5-eesposit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-02-21hw/nvram: use at24 macroPatrick Venture1-1/+1
Use the macro for going from I2CSlave to EEPROMState. Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220119214329.2557049-1-venture@google.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-01-18hw/nvram: Restrict fw_cfg QOM interface to sysemu and toolsPhilippe Mathieu-Daudé1-2/+4
fw_cfg QOM interface is required by system emulation and qemu-storage-daemon. User-mode emulation doesn't need it. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20220111184309.28637-3-f4bug@amsat.org>
2021-12-31dma: Let st*_dma() take MemTxAttrs argumentPhilippe Mathieu-Daudé1-2/+2
Let devices specify transaction attributes when calling st*_dma(). Keep the default MEMTXATTRS_UNSPECIFIED in the few callers. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211223115554.3155328-16-philmd@redhat.com>
2021-12-30dma: Let dma_memory_read/write() take MemTxAttrs argumentPhilippe Mathieu-Daudé1-3/+6
Let devices specify transaction attributes when calling dma_memory_read() or dma_memory_write(). Patch created mechanically using spatch with this script: @@ expression E1, E2, E3, E4; @@ ( - dma_memory_read(E1, E2, E3, E4) + dma_memory_read(E1, E2, E3, E4, MEMTXATTRS_UNSPECIFIED) | - dma_memory_write(E1, E2, E3, E4) + dma_memory_write(E1, E2, E3, E4, MEMTXATTRS_UNSPECIFIED) ) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20211223115554.3155328-6-philmd@redhat.com>
2021-12-30dma: Let dma_memory_set() take MemTxAttrs argumentPhilippe Mathieu-Daudé1-1/+2
Let devices specify transaction attributes when calling dma_memory_set(). Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20211223115554.3155328-3-philmd@redhat.com>
2021-10-23hw/nvram: Fix Memory Leak in Xilinx ZynqMP eFuse deviceTong Ho1-6/+12
Signed-off-by: Tong Ho <tong.ho@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211015203532.2463705-4-tong.ho@xilinx.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-23hw/nvram: Fix Memory Leak in Xilinx Versal eFuse deviceTong Ho1-5/+15
Signed-off-by: Tong Ho <tong.ho@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211015203532.2463705-3-tong.ho@xilinx.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-10-23hw/nvram: Fix Memory Leak in Xilinx eFuse QOMTong Ho1-3/+6
Signed-off-by: Tong Ho <tong.ho@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211015203532.2463705-2-tong.ho@xilinx.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-09-30hw/nvram: Introduce Xilinx battery-backed ramTong Ho3-0/+550
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 Ho3-0/+861
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 Ho4-0/+904
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 Ho4-0/+408
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>
2021-09-13fw_cfg: add etc/msr_feature_controlPaolo Bonzini1-0/+1
The file already existed, but nobody had noticed the warning until now. Add it at the bottom, since that is where unknown files go in legacy mode. Fixes: 217f1b4a721 ("target-i386: Publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg") Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-06-02docs: fix references to docs/devel/tracing.rstStefano Garzarella1-1/+1
Commit e50caf4a5c ("tracing: convert documentation to rST") converted docs/devel/tracing.txt to docs/devel/tracing.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/tracing.txt/tracing.rst/ $(git grep -l docs/devel/tracing.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210517151702.109066-2-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-05-02Do not include exec/address-spaces.h if it's not really necessaryThomas Huth1-1/+0
Stop including exec/address-spaces.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-5-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02Do not include cpu.h if it's not really necessaryThomas Huth1-1/+0
Stop including cpu.h in files that don't need it. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-4-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02hw: Do not include hw/sysbus.h if it is not necessaryThomas Huth1-1/+0
Many files include hw/sysbus.h without needing it. Remove the superfluous include statements. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210327082804.2259480-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-09sysemu: Let VMChangeStateHandler take boolean 'running' argumentPhilippe Mathieu-Daudé1-1/+1
The 'running' argument from VMChangeStateHandler does not require other value than 0 / 1. Make it a plain boolean. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210111152020.1422021-3-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-02-08nvram: add nrf51_soc flash read methodPrasad J Pandit1-0/+10
Add nrf51_soc mmio read method to avoid NULL pointer dereference issue. Reported-by: Lei Sun <slei.casper@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Message-Id: <20200811114133.672647-6-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-01-12hw/*: Use type casting for SysBusDevice in NPCM7XXHao Wu1-1/+1
A device shouldn't access its parent object which is QOM internal. Instead it should use type cast for this purporse. This patch fixes this issue for all NPCM7XX Devices. Signed-off-by: Hao Wu <wuhaotsh@google.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20210108190945.949196-7-wuhaotsh@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-01Merge remote-tracking branch ↵Peter Maydell2-0/+2
'remotes/ehabkost-gl/tags/machine-next-pull-request' into staging Machine queue, 2020-12-23 Cleanup: * qdev code cleanup (Eduardo Habkost) Bug fix: * hostmem: Free host_nodes list right after visited (Keqian Zhu) # gpg: Signature made Wed 23 Dec 2020 21:25:58 GMT # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost-gl/tags/machine-next-pull-request: bugfix: hostmem: Free host_nodes list right after visited qdev: Avoid unnecessary DeviceState* variable at set_prop_arraylen() qdev: Rename qdev_get_prop_ptr() to object_field_prop_ptr() qdev: Move qdev_prop_tpm declaration to tpm_prop.h qdev: Make qdev_class_add_property() more flexible qdev: Make PropertyInfo.create return ObjectProperty* qdev: Move dev->realized check to qdev_property_set() qdev: Wrap getters and setters in separate helpers qdev: Add name argument to PropertyInfo.create method qdev: Add name parameter to qdev_class_add_property() qdev: Avoid using prop->name unnecessarily qdev: Get just property name at error_set_from_qdev_prop_error() sparc: Use DEFINE_PROP for nwindows property qdev: Reuse DEFINE_PROP in all DEFINE_PROP_* macros qdev: Move softmmu properties to qdev-properties-system.h Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-12-19migration: Replace migration's JSON writer by the general oneMarkus Armbruster2-2/+2
Commit 8118f0950f "migration: Append JSON description of migration stream" needs a JSON writer. The existing qobject_to_json() wasn't a good fit, because it requires building a QObject to convert. Instead, migration got its very own JSON writer, in commit 190c882ce2 "QJSON: Add JSON writer". It tacitly limits numbers to int64_t, and strings contents to characters that don't need escaping, unlike qobject_to_json(). The previous commit factored the JSON writer out of qobject_to_json(). Replace migration's JSON writer by it. Cc: Juan Quintela <quintela@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-17-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-12-18qdev: Move softmmu properties to qdev-properties-system.hEduardo Habkost2-0/+2
Move the property types and property macros implemented in qdev-properties-system.c to a new qdev-properties-system.h header. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20201211220529.2290218-16-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-12-10vl: extract softmmu/datadir.cPaolo Bonzini1-0/+1
Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-08fw_cfg: Refactor extra pci roots additionJiahui Cen1-0/+23
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-10-12hw/nvram: Always register FW_CFG_DATA_GENERATOR_INTERFACEPhilippe Mathieu-Daudé3-7/+26
While the FW_CFG_DATA_GENERATOR_INTERFACE is only consumed by a device only available using system-mode (fw_cfg), it is implemented by a crypto component (tls-cipher-suites) which is always available when crypto is used. Commit 69699f3055 introduced the following error in the qemu-storage-daemon binary: $ echo -e \ '{"execute": "qmp_capabilities"}\r\n{"execute": "qom-list-types"}\r\n{"execute": "quit"}\r\n' \ | storage-daemon/qemu-storage-daemon --chardev stdio,id=qmp0 --monitor qmp0 {"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 5}, "package": ""}, "capabilities": ["oob"]}} {"return": {}} missing interface 'fw_cfg-data-generator' for object 'tls-creds' Aborted (core dumped) Since QOM dependencies are resolved at runtime, this issue could not be triggered at linktime, and we don't have test running the qemu-storage-daemon binary. Fix by always registering the QOM interface. Reported-by: Kevin Wolf <kwolf@redhat.com> Fixes: 69699f3055 ("crypto/tls-cipher-suites: Produce fw_cfg consumable blob") Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20201006111909.2302081-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-18Use OBJECT_DECLARE_SIMPLE_TYPE when possibleEduardo Habkost2-6/+2
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-18hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumptionLaszlo Ersek1-1/+1
The documentation on g_byte_array_free() <https://developer.gnome.org/glib/stable/glib-Byte-Arrays.html#g-byte-array-free> says: > Returns > > the element data if free_segment is FALSE, otherwise NULL. The element > data should be freed using g_free(). Because we currently call g_byte_array_free() with free_segment=TRUE, we end up passing data=NULL to fw_cfg_add_file(). On the plus side, fw_cfg_data_read() and fw_cfg_dma_transfer() both deal with NULL data gracefully: QEMU does not crash when the guest reads such an item, the guest just gets a properly sized, but zero-filled blob. However, the bug breaks UEFI HTTPS boot, as the IANA_TLS_CIPHER array, generated otherwise correctly by the "tls-cipher-suites" object, is in effect replaced with a zero blob. Fix the issue by passing free_segment=FALSE to g_byte_array_free(): - the caller (fw_cfg_add_from_generator()) temporarily assumes ownership of the generated byte array, - then ownership of the byte array is transfered to fw_cfg, as fw_cfg_add_file() links (not copies) "data" into fw_cfg. Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Fixes: 3203148917d035b09f71986ac2eaa19a352d6d9d Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200916151510.22767-1-lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-09-14hw/nvram: NPCM7xx OTP device modelHavard Skinnemoen2-0/+441
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 Habkost3-4/+6
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>
generated by cgit v1.1 at 2025-08-03 14:33:35 +0000