@@ -332,16 +332,16 @@ static bool fw_cfg_comb_valid(void *opaque, hwaddr addr,
}
static const MemoryRegionOps fw_cfg_ctl_mem_ops = {
.write = fw_cfg_ctl_mem_write,
- .endianness = DEVICE_NATIVE_ENDIAN,
+ .endianness = DEVICE_BIG_ENDIAN,
.valid.accepts = fw_cfg_ctl_mem_valid,
};
static const MemoryRegionOps fw_cfg_data_mem_ops = {
.read = fw_cfg_data_mem_read,
.write = fw_cfg_data_mem_write,
- .endianness = DEVICE_NATIVE_ENDIAN,
+ .endianness = DEVICE_BIG_ENDIAN,
.valid = {
.min_access_size = 1,
.max_access_size = 1,
},
The standalone selector port (fw_cfg_ctl_mem_ops) is only used by big endian guests to date (*), hence this change doesn't regress them. Paolo and Alex have suggested / requested an explicit DEVICE_BIG_ENDIAN setting here, for clarity. (*) git grep -l fw_cfg_init_mem hw/nvram/fw_cfg.c hw/ppc/mac_newworld.c hw/ppc/mac_oldworld.c hw/sparc/sun4m.c include/hw/nvram/fw_cfg.h The standalone data port (fw_cfg_data_mem_ops) has max_access_size 1 (for now), hence changing its endianness doesn't change behavior for existing guest code. Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- Notes: v5: - new in v5 [Paolo, Alex] hw/nvram/fw_cfg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)