+-- On Tue, 21 Jul 2020, Philippe Mathieu-Daudé wrote --+ | On 7/21/20 8:47 AM, P J P wrote: | > +-- On Thu, 16 Jul 2020, Peter Maydell wrote --+ | > | > The 'flash_ops' is for ROM, though I don't see where it calls | > | > 'memory_region_rom_device_set_romd' to ROMD, so this MR is in MMIO | > | > mode and it needs a read callback. | > | | > | I think that 'romd mode' (ie reads-go-directly-to-RAM) is the default: | > | memory_region_initfn() sets romd_mode to true. So unless the device | > | actively calls memory_region_rom_device_set_romd(mr, false) then the | > | read callback can't be reached. | > | > So, we go with g_assert_not_reached() ? We seem to have differing opinions | > about these callbacks. | | - Callback missing because we neglected to implement the | hardware behavior: | | => qemu_log_mask(LOG_UNIMP, ...) | | - Callback missing because the access is illegal on hardware | (write on read-only register, read on write-only register): | | => qemu_log_mask(LOG_GUEST_ERROR, ...) | | - Impossible situation unrelated to the hardware/guest behavior | (problem in QEMU design) | | => g_assert_not_reached() | | Note, when we runs QEMU with LOG_UNIMP/LOG_GUEST_ERROR enabled, | we are usually interested in what address the guest is accessing, | and in the write case, what value is written.
Okay, preparing a revised patch series. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
