qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [PATCH 4/8] boards.h: Define new flag ignore_memory_trans


From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH 4/8] boards.h: Define new flag ignore_memory_transaction_failures
Date: Thu, 17 Aug 2017 11:25:36 +0100

On 5 August 2017 at 11:13, Peter Maydell <address@hidden> wrote:
> On 4 August 2017 at 20:23, Richard Henderson
> <address@hidden> wrote:
>> On 08/04/2017 11:09 AM, Philippe Mathieu-Daudé wrote:
>>> Since create_unimplemented_device() register overlapped with low priority, 
>>> why
>>> not register it as default device directly, over the whole address space?
>>
>> That's a good suggestion.  It makes more sense to me than adding a flag on 
>> the
>> MachineClass.
>
> Yeah, I did think about implementing it that way, but...
>
> That wouldn't handle the case of a device model directly
> returning a MEMTX_ERROR, or a transaction dispatched to
> a memory region whose MemoryRegionOps valid settings
> prohibit it (eg byte accesses to a word-access-only device),
> or accesses to a MemoryRegion that was created by passing
> a NULL MemoryRegionOps pointer to memory_region_init_io
> (I dunno why you'd do that but some code does).
>
> In short, there are lots of ways the memory subsystem might
> end up returning a transaction error -- this mechanism
> ensures that none of them start generating exceptions
> when they previously did not, and is (I hope) easy to
> review in the sense of being sure that it does what it
> intends to do without the need to audit a lot of corner
> cases.

So, this question (should we have a board flag to disable reporting
of tx failures to the CPU hook, or use unimplemented_device as a
sort of background region) seems to be the main unanswered question
for this series. I think (as outlined above) that the board flag
is simpler and safer; are people happy for me to put this series
in target-arm.next with that approach, or should I rethink this bit?

thanks
-- PMM



reply via email to

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