[Top][All Lists]

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

Re: [PATCH v3] memory: Directly dispatch alias accesses on origin memory

From: Mark Cave-Ayland
Subject: Re: [PATCH v3] memory: Directly dispatch alias accesses on origin memory region
Date: Tue, 20 Apr 2021 08:22:28 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0

On 19/04/2021 22:11, Philippe Mathieu-Daudé wrote:

My patch might not be the proper fix, but we need to figure out how
to avoid others to hit the same problem, as it is very hard to debug.

At least an assertion and a comment.

Something like:

-- >8 --
diff --git a/softmmu/memory.c b/softmmu/memory.c
index d4493ef9e43..e031ac6e074 100644
--- a/softmmu/memory.c
+++ b/softmmu/memory.c
@@ -1442,6 +1442,7 @@ MemTxResult memory_region_dispatch_read(MemoryRegion *mr,
     unsigned size = memop_size(op);
     MemTxResult r;

+    assert(!(mr->alias && !mr>alias_offset)); /* Use AddressSpace API
instead */
     if (!memory_region_access_valid(mr, addr, size, false, attrs)) {
         *pval = unassigned_mem_read(mr, addr, size);
         return MEMTX_DECODE_ERROR;

AFAICT the dispatch functions don't handle rom/ram or aliases so you might need to go a bit stronger. The check is further complicated by the fact that you can have rom/ram devices which do define the underlying mr->ops.

I'm wondering for memory_region_dispatch_read() if this would work?

   assert(!mr->alias && !memory_access_is_direct(mr, false));



reply via email to

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