e935b73508
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> |
||
---|---|---|
.. | ||
chrp_nvram.c | ||
ds1225y.c | ||
eeprom93xx.c | ||
eeprom_at24c.c | ||
fw_cfg-interface.c | ||
fw_cfg.c | ||
Kconfig | ||
mac_nvram.c | ||
meson.build | ||
npcm7xx_otp.c | ||
nrf51_nvm.c | ||
spapr_nvram.c | ||
trace-events | ||
trace.h | ||
xlnx-bbram.c | ||
xlnx-efuse-crc.c | ||
xlnx-efuse.c | ||
xlnx-versal-efuse-cache.c | ||
xlnx-versal-efuse-ctrl.c | ||
xlnx-zynqmp-efuse.c |