Re: Question on Qemu flash driver - pflash_cfi01

[Peter Maydell]

On Sat, 23 Sept 2023 at 13:11, Srivatsa Vaddagiri
<quic_svaddagi@quicinc.com> wrote:
>
> cfi01 driver initializes a rom device with ops represented by 
> pflash_cfi01_ops.
>
> static const MemoryRegionOps pflash_cfi01_ops = {
>     .read_with_attrs = pflash_mem_read_with_attrs,
>     .write_with_attrs = pflash_mem_write_with_attrs,
>     .endianness = DEVICE_NATIVE_ENDIAN,
> };
>
>
>     memory_region_init_rom_device(
>         &pfl->mem, OBJECT(dev),
>         &pflash_cfi01_ops,
>         pfl,
>         pfl->name, total_len, errp);
>
> This region is also mapped in guest address space. For ex: hw/arm/virt.c does
> that by:
>
> virt_flash_map1() {
>
>     memory_region_add_subregion(sysmem, base,
>                 sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0));
> }
>
> It is not clear to me under what circumstance would the callbacks listed in
> pflash_cfi01_ops be invoked. Is rom device memory supposed to be of 
> trap/emulate
> type, so that guest read of that memory will get trapped and handled by ops
> listed in pflash_cfi01_ops? I see that a hypervisor accelerator's memory
> listener callback gets notified of that memory range and appears to be
> registering that as "read-only" memory. A read of that memory range from guest
> need not necessarily cause a trap for example, in which case when would
> pflash_mem_read_with_attrs get invoked?

A "rom device" is (as described in
https://www.qemu.org/docs/master/devel/memory.html) a device which
works like RAM for reads (directly accessing a region of host memory),
but like MMIO for writes (invoking a callback).

ROM devices also have two modes:
 (1) "romd mode" is the default; as above, reads go to memory,
     and writes go to the write function in the MemoryRegionOps
 (2) "romd mode disabled" means that both reads and writes
     go to the functions in the MemoryRegionOps
The device can use memory_region_rom_device_set_romd() to
switch between these.

For the pflash devices, we use these so that in normal
circumstances, execution and reading from the flash is fast.
But the guest still has the ability to reprogram the flash
(by writing commands to it); when the guest is programming the
flash, reads from the device don't return the flash data, they
return command responses. So when the guest starts programming
the flash, the device puts itself into "romd disabled" mode,
so that it can handle the read accesses correctly. Once the
programming has finished it can switch back into romd mode again.

thanks
-- PMM