On 24 July 2015 at 10:55, Pavel Fedin <p.fe...@samsung.com> wrote: > Just speficying ops = NULL in some cases can be more convenient than having
"specifying" > two functions. GICv3 code is going to use this. GICv2 code can be refactored > in a similar way, killing some code duplication. > > Signed-off-by: Pavel Fedin <p.fe...@samsung.com> > Acked-by: Paolo Bonzini <pbonz...@redhat.com> > --- > include/exec/memory.h | 14 +++++++++++--- > memory.c | 10 +--------- > 2 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/include/exec/memory.h b/include/exec/memory.h > index 1394715..3b5e44e 100644 > --- a/include/exec/memory.h > +++ b/include/exec/memory.h > @@ -436,6 +436,9 @@ void memory_region_init_alias(MemoryRegion *mr, > * memory_region_init_rom_device: Initialize a ROM memory region. Writes > are > * handled via callbacks. > * > + * If NULL callbacks pointer is given, then I/O space is not supposed to be > + * handled by QEMU itself. Any access via the memory API will cause an > abort(). I know the memory_region_init_reservation() documentation says this, but is it true? Looking at the memory.c and exec.c code it seems like we'd return MEMTX_DECODE_ERROR for callers who care about memory transaction statuses, behave as RAZ/WI for the bulk of callers that don't, and maybe print some debug logging, but I can't see a relevant call to abort()... Paolo? (For the avoidance of doubt, if this is an error in the doc text I don't insist on it being fixed before this patch is applied.) thanks -- PMM
