[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 1/6] Merge memory_region_init_reservation() i

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v7 1/6] Merge memory_region_init_reservation() into memory_region_init_io()
Date: Fri, 24 Jul 2015 17:20:56 +0100

On 24 July 2015 at 10:55, Pavel Fedin <address@hidden> wrote:
> Just speficying ops = NULL in some cases can be more convenient than having


> 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 <address@hidden>
> Acked-by: Paolo Bonzini <address@hidden>
> ---
>  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()...


(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.)

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]