@samitouri / QOSamiQemu / commits / 9f733abb1a

system/memory: assert on invalid MemoryRegionOps .unaligned combo

When it comes to this pattern: .valid.unaligned = false and impl.unaligned = true, is effectlvely contradictory. The .valid structure indicates that unaligned access should be rejected at the access validation phase, yet .impl suggests the underlying device implementation can handle unaligned operations. As a result, the upper-layer code will never even reach the .impl logic. Add an assertion that the MemoryRegionOps doesn't specify this invalid combination. Signed-off-by: CJ Chen <cjchen@igel.co.jp> Tested-by: CJ Chen <cjchen@igel.co.jp> Suggested-by: Peter Xu <peterx@redhat.com> Acked-by: Tomoyuki Hirose <hrstmyk811m@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> [PMM: tweaked commit message] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Link: https://lore.kernel.org/r/20260428093339.2087081-5-peter.maydell@linaro.org Signed-off-by: Peter Xu <peterx@redhat.com>

CJ Chen committed Apr 28, 2026 at 10:33 UTC 9f733abb1aa44be23961b7fa0856945928504a50
1 file changed +1
system/memory.c
+1
@@ -1573,6 +1573,7 @@ void memory_region_init_io(MemoryRegion *mr, Object *owner,
1573 const MemoryRegionOps *ops, void *opaque,
1574 const char *name, uint64_t size)
1575 {
1576 + g_assert(!ops || !(ops->impl.unaligned && !ops->valid.unaligned));
1577 memory_region_init(mr, owner, name, size);
1578 memory_region_set_ops(mr, ops, opaque);
1579 }