qemu-devel
[Top][All Lists]
Advanced

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

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


From: Richard Henderson
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH 4/8] boards.h: Define new flag ignore_memory_transaction_failures
Date: Thu, 24 Aug 2017 13:28:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 22 August 2017 at 09:36, Peter Maydell <address@hidden> wrote:
> On 22 August 2017 at 04:45, Philippe Mathieu-Daudé <address@hidden> wrote:
>> If we are worried about being backward compatible, defaulting background
>> region to unimp() won't throw any transaction error.
>
> As I said, it will, for the cases of 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), etc.
> The only simple way to guarantee that we don't generate exceptions
> on transaction errors is to cause the hook not to be called
> (or to have the hook decide to do nothing, I suppose).
>
>> I'm somehow afraid that "ignore_memory_transaction_failures" ends up like
>> the "cannot_instantiate_with_device_add_yet" flag - a hard to remove kludge
>> outliving his purpose.
>
> I agree that it's going to be around for a long time, possibly
> forever, but that's life when we have so many old boards.
> Any approach we take is almost certainly going to be hanging
> around forever.
>
>> Anyway I'm not unhappy with this approach, but I'd be very happy to have
>> unimp() covering the whole background region.
>
> I think this would be a reasonable approach for converting
> boards away from this ignore_memory_transaction_failures hook
> on a board-by-board basis but you'd still want to test some
> common guest software for each conversion.

Peter and I had a chat on IRC about this.

While I think the background region idea is tempting, it does nothing to help
legacy boards once devices start signaling their own errors.  Therefore some
sort of flag is the only reasonable solution.


r~



reply via email to

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