From aa6c6ae843cbdc251224bc6170d2663ac929b04f Mon Sep 17 00:00:00 2001 From: Laszlo Ersek Date: Tue, 29 Nov 2016 20:55:32 +0100 Subject: loader: fix handling of custom address spaces when adding ROM blobs * Commit 3e76099aacb4 ("loader: Allow a custom AddressSpace when loading ROMs") introduced the "Rom.as" field: (1) It modified the utility callers of rom_insert() to take "as" as a new parameter from *their* callers, and set "rom->as" from that parameter. The functions covered were rom_add_file() and rom_add_elf_program(). (2) It also modified rom_insert() itself, to auto-assign "&address_space_memory", in case the external caller passed -- and the utility caller forwarded -- as=NULL. Except, commit 3e76099aacb4 forgot to update the third utility caller of rom_insert(), under point (1), namely rom_add_blob(). * Later, commit 5e774eb3bd264 ("loader: Add AddressSpace loading support to uImages") added the load_uimage_as() function, and the rom_add_blob_fixed_as() function-like macro, with the necessary changes elsewhere to propagate the new "as" parameter to rom_add_blob(): load_uimage_as() load_uboot_image() rom_add_blob_fixed_as() rom_add_blob() At this point, the signature (and workings) of rom_add_blob() had been broken already, and the rom_add_blob_fixed_as() macro passed its "_as" parameter to rom_add_blob() as "callback_opaque". Given that the "fw_callback" parameter itself was set to NULL (correctly), this did no additional damage (the opaque arg would never be used), but ultimately it broke the new functionality of load_uimage_as(). * The load_uimage_as() function would be put to use in one of the later patches, commit e481a1f63c93 ("generic-loader: Add a generic loader"). * We can fix this only in a unified patch now. Append "AddressSpace *as" to the signature of rom_add_blob(), and handle the new parameter. Pass NULL from all current callers, except from rom_add_blob_fixed_as(), where "_as" has to be bumped to the proper position. * Note that rom_add_file() rejects the case when both "mr" and "as" are passed in as non-NULL. The action that this is apparently supposed to prevent is the rom->mr = mr; assignment (that's the only place where the "mr" parameter is used in rom_add_file()). In rom_add_blob() though, we have no "mr" parameter, and the actions done on the fw_cfg branch: if (fw_file_name && fw_cfg) { if (mc->rom_file_has_mr) { data = rom_set_mr(rom, OBJECT(fw_cfg), devpath); mr = rom->mr; } else { data = rom->data; } reflect those that are performed by rom_add_file() too (with mr==NULL): if (rom->fw_file && fw_cfg) { if ((!option_rom || mc->option_rom_has_mr) && mc->rom_file_has_mr) { data = rom_set_mr(rom, OBJECT(fw_cfg), devpath); } else { data = rom->data; } Hence we need no additional restrictions in rom_add_blob(). * Stable is not affected as both problematic commits appeared first in v2.8.0-rc0. Cc: "Michael S. Tsirkin" Cc: Alistair Francis Cc: Igor Mammedov Cc: Michael Walle Cc: Paolo Bonzini Cc: Peter Maydell Cc: Shannon Zhao Cc: qemu-arm@nongnu.org Cc: qemu-devel@nongnu.org Fixes: 3e76099aacb4dae0d37ebf95305369e03d1491e6 Fixes: 5e774eb3bd264c76484906f4bd0fb38e00b8090e Signed-off-by: Laszlo Ersek Reviewed-by: Alistair Francis Reviewed-by: Michael S. Tsirkin Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/lm32/lm32_hwsetup.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hw/lm32') diff --git a/hw/lm32/lm32_hwsetup.h b/hw/lm32/lm32_hwsetup.h index b71e6ea..23e1878 100644 --- a/hw/lm32/lm32_hwsetup.h +++ b/hw/lm32/lm32_hwsetup.h @@ -75,7 +75,7 @@ static inline void hwsetup_create_rom(HWSetup *hw, hwaddr base) { rom_add_blob("hwsetup", hw->data, TARGET_PAGE_SIZE, - TARGET_PAGE_SIZE, base, NULL, NULL, NULL); + TARGET_PAGE_SIZE, base, NULL, NULL, NULL, NULL); } static inline void hwsetup_add_u8(HWSetup *hw, uint8_t u) -- cgit v1.1