[{"id":3679333,"web_url":"http://patchwork.ozlabs.org/comment/3679333/","msgid":"","list_archive_url":null,"date":"2026-04-20T09:51:37","subject":"Re: [PATCH] system/memory: Don't call MR handlers for bytes beyond\n the MR's size","submitter":{"id":5111,"url":"http://patchwork.ozlabs.org/api/people/5111/","name":"Peter Maydell","email":"peter.maydell@linaro.org"},"content":"On Mon, 20 Apr 2026 at 08:52, Thomas Huth wrote:\n>\n> From: Thomas Huth \n>\n> If a guest triggers a multi-byte read/write at the very end of a memory\n> region, the code access_with_adjusted_size() still tries to access\n> all bytes of the transfer, even if the final bytes are already beyond\n> the memory region's size. If the device handler cannot cope with those\n> accesses, bad things can happen, for example:\n>\n> $ echo \"writew 0x800064 0x4142\" | \\\n> ./qemu-system-avr -M mega2560 -display none -qtest stdio -accel qtest\n> [I 0.000001] OPENED\n> [R +0.001750] writew 0x800064 0x4142\n> qemu-system-avr: ../../devel/qemu/hw/misc/avr_power.c:58:\n> avr_mask_write: Assertion `offset == 0' failed.\n> Aborted (core dumped)\n>\n> We really should not call MR handlers for bytes that are beyond the\n> MR's size, so let's add a check to limit the size in such cases.\n>\n> Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3393\n> Signed-off-by: Thomas Huth \n\nThe MR in question sets .impl.max_access_size to 1 but leaves\n.valid.max_access_size at its default (which we treat as 4),\nand is then registered with an MR size of 1. Perhaps we should\nalso assert on MR registration that\n .valid.max_access_size <= the MR size ?\nThough there might I suppose be cases where the MR window can be\nguest-configured to various sizes so it might in some silly setups\nbe smaller than the largest permitted access size on startup.\n\nWe should also set .valid.max_access_size on this specific\ndevice to 1, though the fix to the core memory system is\ndefinitely something we should have (and that I was under\nthe impression we already enforced...)\n\n> ---\n> system/memory.c | 13 +++++++++++--\n> 1 file changed, 11 insertions(+), 2 deletions(-)\n>\n> diff --git a/system/memory.c b/system/memory.c\n> index 56f3225b21a..2ff74c42e3f 100644\n> --- a/system/memory.c\n> +++ b/system/memory.c\n> @@ -531,6 +531,7 @@ static MemTxResult access_with_adjusted_size(hwaddr addr,\n> uint64_t access_mask;\n> unsigned access_size;\n> unsigned i;\n> + unsigned int checked_size;\n> MemTxResult r = MEMTX_OK;\n> bool reentrancy_guard_applied = false;\n>\n> @@ -557,13 +558,21 @@ static MemTxResult access_with_adjusted_size(hwaddr addr,\n> /* FIXME: support unaligned access? */\n> access_size = MAX(MIN(size, access_size_max), access_size_min);\n> access_mask = MAKE_64BIT_MASK(0, access_size * 8);\n> +\n> + if (addr + size > mr->size) {\n\nmr->size is an Int128 -- you can't portably do direct\narithmetic on it like this. (We still support configs where\nthere is no working __int128_t and Int128 is a struct.\nI think --enable-tcg-interpreter is one way to get that.)\n\nThere are also I think cases where addr + size might overflow.\n(addr is the within-MR offset, but we permit MR sizes up to\nand including 2^64.)\n\n> + assert(addr < mr->size);\n> + checked_size = mr->size - addr;\n> + } else {\n> + checked_size = size;\n> + }\n\nI wonder if this is the right place to enforce this.\nAnother option would be to have memory_region_access_valid()\ndo the check and return false for accesses off the end.\nThe splitting of writes that we do here is only supposed to be\nhandling the case of \"the implementation allows smaller chunks\nthan the device permits\", not the \"access overlaps between two\ndifferent MRs\" case (which would need to be handled much further\nup the callstack before we have identified the specific MR we\nare accessing).\n\n> +\n> if (devend_big_endian(mr->ops->endianness)) {\n> - for (i = 0; i < size; i += access_size) {\n> + for (i = 0; i < checked_size; i += access_size) {\n> r |= access_fn(mr, addr + i, value, access_size,\n> (size - access_size - i) * 8, access_mask, attrs);\n> }\n> } else {\n> - for (i = 0; i < size; i += access_size) {\n> + for (i = 0; i < checked_size; i += access_size) {\n> r |= access_fn(mr, addr + i, value, access_size, i * 8,\n> access_mask, attrs);\n> }\n\nthanks\n-- PMM","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=JJjW/yoV;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fzglP48k7z1yD4\n\tfor ; Mon, 20 Apr 2026 19:52:47 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wElIR-0006ky-CA; Mon, 20 Apr 2026 05:52:04 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wElIH-0006k5-14\n for qemu-devel@nongnu.org; Mon, 20 Apr 2026 05:51:54 -0400","from mail-yx1-xb133.google.com ([2607:f8b0:4864:20::b133])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wElIE-0005YZ-QN\n for qemu-devel@nongnu.org; Mon, 20 Apr 2026 05:51:52 -0400","by mail-yx1-xb133.google.com with SMTP id\n 956f58d0204a3-651bc8f864fso1478113d50.1\n for ; Mon, 20 Apr 2026 02:51:49 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776678709; cv=none;\n d=google.com; s=arc-20240605;\n b=XJdEJufAfz8qISeoqmkAg5DRbbJQ6fPq86yGUyqyx2ihG6pdSYcW2hJCzZk9DSfigt\n Oygv2mjc7nkODJjSaBYj2lzoEt9DjodocZlcwjZc4A3R96+v/JpLFBxsZa/g/Y73NQuv\n 6uEvZik7q2c88wFAO+CuFjUwiVotkXNoiDV/YWT3B19RFlxKv4j/jZgr5+fEiyyVwFCR\n 8fHjOYwT1Cn+jVmFhXO+6Yw/wq/muuk6CiWwKAGIcFJAsUSZdSU8knt5ctIOSVnQmyp0\n Zx0rfLtoPCaay7pASkUd0Ci161AObkXbT8i6GepZcAsq73C9D38kjncV6YBUwe6rjWUI\n 4+Rw==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=CM248gn6ZX0X3LvYoKmqT1dJlvLJmbmpAU7NIAOnodo=;\n fh=N3dnZwB1bGIoIuwtamz7lHcb5DEaPuY10mwMPlmH8No=;\n b=DNCBKZ/aTxXUFmRVbvgNa6f/wn819Yy0L5jHroI/EXjumh1bK62vqvWrDnjHSeHGFi\n aiPJiKgbMMfA14fwnporXBrQQEFvwSKyRggnO9fKYh6BcQTVcGpn9D/8nzS9Pi+y/bNn\n dZjvu2oZZJrWoEWeljX/GSu7YdoOS75fdGpBBY1ud05HQP/PQw82u4FWAcgco26Aaa8S\n iglv1Mo39eeBxcNAU6HzAvqum4XZ926Isb6EnsVCMTDeL2+L09+89h5LAkNhLhr61C97\n vG4fvMP6+ftS4vFv43EFXB0y/ifXtA2FcOn22/1pfS7dglOS21hUDuA4AdCHV9KpX7eu\n aqKQ==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776678709; x=1777283509; darn=nongnu.org;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=CM248gn6ZX0X3LvYoKmqT1dJlvLJmbmpAU7NIAOnodo=;\n b=JJjW/yoVVHUiPcOYYiOL7ttJ0qZEU6GVNtXSoi7QIbncD3GJuo8oHbyNnKwHg6atv3\n 6I+XBFJW+ksXdwN9Lmit5FaoR7hYlOPt5cyUUd1uMmr3zK8j2dzZK1sYGaVB5z7FPOcM\n JyKoO8aYxkllBa2uno48cB2xt7su15q1XZ8xHYal5yfnXKp+s4ZP1s5Fuu2PjUyILfdN\n MoW4d7ZByB6voE91TkbUwJrrb0oUmW5BynXvPYVW+bxGBPSjmMSToPGZz4FwplrHwjFC\n cawWp+2PwC2p3G6+FTNkhYhEsBurc/Y07HaBApmTOuAU0kV6jSXNI3d8/JW3B3VLCZz8\n uCjQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776678709; x=1777283509;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=CM248gn6ZX0X3LvYoKmqT1dJlvLJmbmpAU7NIAOnodo=;\n b=DYqBThqr4qDIi5Z4v9lh2N9viOxwodLILmRTK4YB6tkU9ISgFHtAE8soMZorO0Pl9W\n GX1TrUfwTng1mwr+u6AnAgnJ9ZbHfCacHskdR5hUGvpiGRz9BfU+AAkYjTtis+UmB592\n H4kQVd6UiGiFB2U3wkaRZWu1I/ri/MUgO9AFInIfGQBQrTyazjYZVZpz9r4iCVs0Gv89\n 0Vx/7tq8KSbsQxBrB+xI24qFtlN14LF+s/o6V3Q8OlhGYk42KzwTTflXaHlRZ32AcWCd\n uLe+qI9sNVjUzgDMPZMvbLVnFV3CPf0shAw11r6Q8/9iHvtWHXNa7aqzDJWH2HWEFE7s\n rTSg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/ddcR3bw/E33aYjD03o+Imstc4Vt47TS+02B2MZrgtVoZQYPpu7CEuV639K422KCc/8bSzsDLbVaYy@nongnu.org","X-Gm-Message-State":"AOJu0YzNbXRmRDIDGuMSevXofZuOMXhyxqBVtzTQzoh3CCt1Bt7Frhbs\n xUcvMjZxNHmkkjoXxGVq0iuCzBmTtnRyhx13l1ym15WAHzPAMYOgIfErXTUFfuN1qFlx7iSC2rT\n 46rqeHM9OO8VWHxpytoZa1RtvWqFkgvd+HQmwf+0Vbg==","X-Gm-Gg":"AeBDies91hPIaliWnNj/JQ98tOUwQZ36c2W+h6LVmRLKy63kmgBAS1xvchchl1lAPRx\n OnYK83QHSuBjo8JKsBA+06tUpIBrpn5Im+GyRtyhHZEtu/PUPsOk2MGj35LmunFa/b9Y3xddW5u\n ULwwE0E9NJZ9aG8eVJtXArvO4rEFnagmoaoFXNyTU/ZW4yN2F1Bry7TT2mokIwOpirJKDZKmRhg\n aWIOogx6uk3SkeLsnEfDtgxHhzjg4DfSTDMccSznnFBSSn+P3vpPuLnGwEF17FvAuQ6ygLcEsG9\n pxlm/pOZnvzn5wmFDH6986JTJIrGdjwMmOCcRhleJ6aftijkeTz0BKnC89lLMmkE+Wor1hXNI21\n 6Sg==","X-Received":"by 2002:a05:690e:585:b0:651:bcb6:888f with SMTP id\n 956f58d0204a3-653108399a9mr8955591d50.15.1776678708741; Mon, 20 Apr 2026\n 02:51:48 -0700 (PDT)","MIME-Version":"1.0","References":"<20260420075159.106615-1-thuth@redhat.com>","In-Reply-To":"<20260420075159.106615-1-thuth@redhat.com>","From":"Peter Maydell ","Date":"Mon, 20 Apr 2026 10:51:37 +0100","X-Gm-Features":"AQROBzBKDHz6c2PHgKACOKjC1CN5yOruVHatehWrcjGlNJl2CaW0Bhq2UEPJvbk","Message-ID":"\n ","Subject":"Re: [PATCH] system/memory: Don't call MR handlers for bytes beyond\n the MR's size","To":"Thomas Huth ","Cc":"Paolo Bonzini , Peter Xu ,\n qemu-devel@nongnu.org,\n =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ","Content-Type":"text/plain; charset=\"UTF-8\"","Received-SPF":"pass client-ip=2607:f8b0:4864:20::b133;\n envelope-from=peter.maydell@linaro.org; helo=mail-yx1-xb133.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3679729,"web_url":"http://patchwork.ozlabs.org/comment/3679729/","msgid":"","list_archive_url":null,"date":"2026-04-21T08:20:49","subject":"Re: [PATCH] system/memory: Don't call MR handlers for bytes beyond\n the MR's size","submitter":{"id":66152,"url":"http://patchwork.ozlabs.org/api/people/66152/","name":"Thomas Huth","email":"thuth@redhat.com"},"content":"On 20/04/2026 11.51, Peter Maydell wrote:\n> On Mon, 20 Apr 2026 at 08:52, Thomas Huth wrote:\n>>\n>> From: Thomas Huth \n>>\n>> If a guest triggers a multi-byte read/write at the very end of a memory\n>> region, the code access_with_adjusted_size() still tries to access\n>> all bytes of the transfer, even if the final bytes are already beyond\n>> the memory region's size. If the device handler cannot cope with those\n>> accesses, bad things can happen, for example:\n>>\n>> $ echo \"writew 0x800064 0x4142\" | \\\n>> ./qemu-system-avr -M mega2560 -display none -qtest stdio -accel qtest\n>> [I 0.000001] OPENED\n>> [R +0.001750] writew 0x800064 0x4142\n>> qemu-system-avr: ../../devel/qemu/hw/misc/avr_power.c:58:\n>> avr_mask_write: Assertion `offset == 0' failed.\n>> Aborted (core dumped)\n>>\n>> We really should not call MR handlers for bytes that are beyond the\n>> MR's size, so let's add a check to limit the size in such cases.\n>>\n>> Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3393\n>> Signed-off-by: Thomas Huth \n> \n> The MR in question sets .impl.max_access_size to 1 but leaves\n> .valid.max_access_size at its default (which we treat as 4),\n> and is then registered with an MR size of 1. Perhaps we should\n> also assert on MR registration that\n> .valid.max_access_size <= the MR size ?\n\nSounds like a good idea, but after a doing a quick check, it seems to me \nthat we've got this pattern all over the place (see e.g. the \"pcspk\" or \n\"kvmvapic\" devices), so this would require a lot of clean-up patches first...\n\n> Though there might I suppose be cases where the MR window can be\n> guest-configured to various sizes so it might in some silly setups\n> be smaller than the largest permitted access size on startup.\n> \n> We should also set .valid.max_access_size on this specific\n> device to 1, though the fix to the core memory system is\n> definitely something we should have (and that I was under\n> the impression we already enforced...)\n\nAgreed, it makes sense to fix the .valid.max_access_size in that avr device. \nI'll send a separate patch for it.\n\n>> ---\n>> system/memory.c | 13 +++++++++++--\n>> 1 file changed, 11 insertions(+), 2 deletions(-)\n>>\n>> diff --git a/system/memory.c b/system/memory.c\n>> index 56f3225b21a..2ff74c42e3f 100644\n>> --- a/system/memory.c\n>> +++ b/system/memory.c\n>> @@ -531,6 +531,7 @@ static MemTxResult access_with_adjusted_size(hwaddr addr,\n>> uint64_t access_mask;\n>> unsigned access_size;\n>> unsigned i;\n>> + unsigned int checked_size;\n>> MemTxResult r = MEMTX_OK;\n>> bool reentrancy_guard_applied = false;\n>>\n>> @@ -557,13 +558,21 @@ static MemTxResult access_with_adjusted_size(hwaddr addr,\n>> /* FIXME: support unaligned access? */\n>> access_size = MAX(MIN(size, access_size_max), access_size_min);\n>> access_mask = MAKE_64BIT_MASK(0, access_size * 8);\n>> +\n>> + if (addr + size > mr->size) {\n> \n> mr->size is an Int128 -- you can't portably do direct\n> arithmetic on it like this. (We still support configs where\n> there is no working __int128_t and Int128 is a struct.\n> I think --enable-tcg-interpreter is one way to get that.)\n> \n> There are also I think cases where addr + size might overflow.\n> (addr is the within-MR offset, but we permit MR sizes up to\n> and including 2^64.)\n\nAh, right ... I'll ponder about how to do this best (and your comment below) \nand will try to come up with a better solution.\n\n Thanks,\n Thomas\n\n\n>> + assert(addr < mr->size);\n>> + checked_size = mr->size - addr;\n>> + } else {\n>> + checked_size = size;\n>> + }\n> \n> I wonder if this is the right place to enforce this.\n> Another option would be to have memory_region_access_valid()\n> do the check and return false for accesses off the end.\n> The splitting of writes that we do here is only supposed to be\n> handling the case of \"the implementation allows smaller chunks\n> than the device permits\", not the \"access overlaps between two\n> different MRs\" case (which would need to be handled much further\n> up the callstack before we have identified the specific MR we\n> are accessing).\n> \n>> +\n>> if (devend_big_endian(mr->ops->endianness)) {\n>> - for (i = 0; i < size; i += access_size) {\n>> + for (i = 0; i < checked_size; i += access_size) {\n>> r |= access_fn(mr, addr + i, value, access_size,\n>> (size - access_size - i) * 8, access_mask, attrs);\n>> }\n>> } else {\n>> - for (i = 0; i < size; i += access_size) {\n>> + for (i = 0; i < checked_size; i += access_size) {\n>> r |= access_fn(mr, addr + i, value, access_size, i * 8,\n>> access_mask, attrs);\n>> }\n> \n> thanks\n> -- PMM\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=HzAX4h7f;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=google header.b=L5nVmplu;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g0Fgg5j8Mz1yCv\n\tfor ; Tue, 21 Apr 2026 18:21:34 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wF6Lr-0002sj-V0; Tue, 21 Apr 2026 04:21:00 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1wF6Lq-0002sb-J7\n for qemu-devel@nongnu.org; Tue, 21 Apr 2026 04:20:58 -0400","from us-smtp-delivery-124.mimecast.com ([170.10.129.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1wF6Lo-0006JY-IF\n for qemu-devel@nongnu.org; Tue, 21 Apr 2026 04:20:58 -0400","from mail-wr1-f71.google.com (mail-wr1-f71.google.com\n [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-665-dlJfBJsWMc-FgZv_sttCmw-1; Tue, 21 Apr 2026 04:20:52 -0400","by mail-wr1-f71.google.com with SMTP id\n ffacd0b85a97d-43d744128b9so3239192f8f.0\n for ; Tue, 21 Apr 2026 01:20:52 -0700 (PDT)","from [192.168.0.9] ([47.64.114.147])\n by smtp.gmail.com with ESMTPSA id\n 5b1f17b1804b1-4891df9e50asm113205585e9.0.2026.04.21.01.20.49\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Tue, 21 Apr 2026 01:20:50 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1776759654;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;\n bh=IdtxoJBKEeqBPrAjHxjAM6FM9fwct2mtiU1n3ybRpzU=;\n b=HzAX4h7fKlipELtk2iqb/RAQ9g2vcSs500gCXzvFjbHLfLSxhfr3IMo05Tkg5zTl5yq5F9\n S0aFcxCM1E2uzLEsN+3mIipYQStC+FSA21MFmHQfySlJMP6kupn5EEOipAxSgGpBq9I9ws\n h/NshtQ4mak8mhNtDiUvpfPIbAlMy7s=","v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=redhat.com; s=google; t=1776759651; x=1777364451; darn=nongnu.org;\n h=content-transfer-encoding:in-reply-to:autocrypt:from\n :content-language:references:cc:to:subject:user-agent:mime-version\n :date:message-id:from:to:cc:subject:date:message-id:reply-to;\n bh=IdtxoJBKEeqBPrAjHxjAM6FM9fwct2mtiU1n3ybRpzU=;\n b=L5nVmplu/L+PBaixdmL26i/SufkpjvfaeY79RqaQ93E+UFfSOtRmH1uAE4xTiRpmpn\n 9gSMiXKKVp9vVikVFjS/whpC2GqHwupM2YGTnk9Fv4zqJoo5c8D3osBgTMOyWzLA7Y/T\n oetzaHgMglume7xDSdvO/ZehJV6LjgKw6adgLxyEDXvoW4zMNndtUd+hOddOGB1OpC4V\n tGi/QYehrGKLoGMtDSYPhZ04BjGs/dBV+NmM9GUc+NnXVsXNTfN/dhrmMorW2fZ82rJd\n CkWplWriGY7vJukD4CjM0x4V42LZPq3Pu9NFd/9kufZpFgIlZemGCJNFOnVwJ2y+uT6s\n JqaA=="],"X-MC-Unique":"dlJfBJsWMc-FgZv_sttCmw-1","X-Mimecast-MFC-AGG-ID":"dlJfBJsWMc-FgZv_sttCmw_1776759651","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776759651; x=1777364451;\n h=content-transfer-encoding:in-reply-to:autocrypt:from\n :content-language:references:cc:to:subject:user-agent:mime-version\n :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=IdtxoJBKEeqBPrAjHxjAM6FM9fwct2mtiU1n3ybRpzU=;\n b=Zs6P77o31uakEutPZNNIGze6FaOjYk0B+LxLUbIDTShYU5CYlww+3lzq1DT30WzKFk\n N/G6BQ4PwRgmY/jyn+N0wEE0Yf/AXjDi3Y3wD3eMnk/ZlKrwODI4hWPsV2+fYE2T6s8Z\n UpTri3EREHQm/An1jxSh0Tedoezb26PmI5xHTCL8FH9+b+O1BiJPk9/DbK19+7ke8Y0S\n j3g6TVFQPvvP0G296+6lzfqV3gJc+wCSTfnmGHcN5BcBUHH3ZkGsUrS2BS7t8HRGatGo\n fbBauyxzNwiZhnYbFUHnFBQx8J3Udfr9V9nlpUEmgFCuFddWB51vlljgc2XwkU5ao+Rl\n K/1A==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+bVqhDZDrb0eztOADgznnubRsqK61JXn841rhxwX03suceHrs6/jAR4FQ5OGPn7bCyrIClQuonX97F@nongnu.org","X-Gm-Message-State":"AOJu0YxRcvspXV0W+AtZUffFOYc3mYHrIBTQMuhH5B809aCNGA7ZRb1N\n Gh/p4wLU9GZrUJCMr7DEGf/QWZ1Bk2q69XEzZXhcro6zOCP1LpHHF5qffx0msFlSURVHbKDdgaa\n q9LVFpyaUYlj0PvCNLFShDDpxM8UzDRLCVYoMaqNHKkNCEmzEMIgH6PQi","X-Gm-Gg":"AeBDiesoq1tgU8fGG6SnFyoHQPxjzOacZia6fq+VyyrqRvmE7/Dwa/1whdhbeGWSOl7\n /Ud7DvJ+cdzgehZimKgyHon17CxRfYgt9DhQ9VGoKs9myu9vdkMH9J/qEFwvssC99rZquROaIFP\n Jdp2PnWQI1QDGD/hVL/VoIXDnbR9bziDiMtvqWdKALx7QSpPh0gWGxpuQVDdsk3OeJH2M2avp6B\n rzI+NyAKBjl0dCDiHQuSIQy+YtmKr7hvyjVEejbqN5SVXBGP4vV6EikzoRVSyj3I9vWKD78RIOd\n xRnQpJfJHkHTT9LHi33zrKYrcU+V9e3rp1j1q0goZihshdxermbI34tEcmztXWuvuBNoY0zRTQQ\n zbYnSYHHbuLdd8INayO7cF9DzGdxiPA==","X-Received":["by 2002:a05:600c:5299:b0:48a:5342:36b5 with SMTP id\n 5b1f17b1804b1-48a54514646mr47553075e9.21.1776759651297;\n Tue, 21 Apr 2026 01:20:51 -0700 (PDT)","by 2002:a05:600c:5299:b0:48a:5342:36b5 with SMTP id\n 5b1f17b1804b1-48a54514646mr47552585e9.21.1776759650762;\n Tue, 21 Apr 2026 01:20:50 -0700 (PDT)"],"Message-ID":"","Date":"Tue, 21 Apr 2026 10:20:49 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] system/memory: Don't call MR handlers for bytes beyond\n the MR's size","To":"Peter Maydell ","Cc":"Paolo Bonzini , Peter Xu ,\n qemu-devel@nongnu.org,\n =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ","References":"<20260420075159.106615-1-thuth@redhat.com>\n ","Content-Language":"en-US","From":"Thomas Huth ","Autocrypt":"addr=thuth@redhat.com; keydata=\n xsFNBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU\n yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2\n 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW\n tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O\n 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81\n O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW\n 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH\n gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr\n 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ\n zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABzR5UaG9tYXMgSHV0\n aCA8dGh1dGhAcmVkaGF0LmNvbT7CwXgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW\n AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK\n QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX\n EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV\n 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD\n eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k\n ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq\n zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG\n tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6\n WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7\n UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDzsFN\n BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4\n 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa\n +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH\n 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K\n gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/\n WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ\n VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq\n knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV\n cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB\n X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABwsFfBBgBAgAJBQJR+3lM\n AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn\n ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k\n fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS\n 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK\n cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV\n ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17\n Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD\n oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs\n IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a\n yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","Received-SPF":"pass client-ip=170.10.129.124; envelope-from=thuth@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}},{"id":3679744,"web_url":"http://patchwork.ozlabs.org/comment/3679744/","msgid":"","list_archive_url":null,"date":"2026-04-21T08:39:35","subject":"Re: [PATCH] system/memory: Don't call MR handlers for bytes beyond\n the MR's size","submitter":{"id":5111,"url":"http://patchwork.ozlabs.org/api/people/5111/","name":"Peter Maydell","email":"peter.maydell@linaro.org"},"content":"On Tue, 21 Apr 2026 at 09:20, Thomas Huth wrote:\n>\n> On 20/04/2026 11.51, Peter Maydell wrote:\n> > On Mon, 20 Apr 2026 at 08:52, Thomas Huth wrote:\n> >>\n> >> From: Thomas Huth \n> >>\n> >> If a guest triggers a multi-byte read/write at the very end of a memory\n> >> region, the code access_with_adjusted_size() still tries to access\n> >> all bytes of the transfer, even if the final bytes are already beyond\n> >> the memory region's size. If the device handler cannot cope with those\n> >> accesses, bad things can happen, for example:\n> >>\n> >> $ echo \"writew 0x800064 0x4142\" | \\\n> >> ./qemu-system-avr -M mega2560 -display none -qtest stdio -accel qtest\n> >> [I 0.000001] OPENED\n> >> [R +0.001750] writew 0x800064 0x4142\n> >> qemu-system-avr: ../../devel/qemu/hw/misc/avr_power.c:58:\n> >> avr_mask_write: Assertion `offset == 0' failed.\n> >> Aborted (core dumped)\n> >>\n> >> We really should not call MR handlers for bytes that are beyond the\n> >> MR's size, so let's add a check to limit the size in such cases.\n> >>\n> >> Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3393\n> >> Signed-off-by: Thomas Huth \n> >\n> > The MR in question sets .impl.max_access_size to 1 but leaves\n> > .valid.max_access_size at its default (which we treat as 4),\n> > and is then registered with an MR size of 1. Perhaps we should\n> > also assert on MR registration that\n> > .valid.max_access_size <= the MR size ?\n>\n> Sounds like a good idea, but after a doing a quick check, it seems to me\n> that we've got this pattern all over the place (see e.g. the \"pcspk\" or\n> \"kvmvapic\" devices), so this would require a lot of clean-up patches first...\n\nI realized yesterday while looking at something else that for\nthe IO case (i.e. x86 in/out insns, not memory-mapped) the\naccess size really can be bigger than the mapped size. There's\na comment in address_space_translate_internal() that mentions this:\n\n /* MMIO registers can be expected to perform full-width accesses based only\n * on their address, without considering adjacent registers that could\n * decode to completely different MemoryRegions. When such registers\n * exist (e.g. I/O ports 0xcf8 and 0xcf9 on most PC chipsets), MMIO\n * regions overlap wildly. For this reason we cannot clamp the accesses\n * here.\n\nPort 0xcf8 is for PCI probing and is 32-bits wide; 0xcf9 is to\ndo with triggering reset.\n\nthanks\n-- PMM","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=yVGClDDK;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g0G5Y2Lr3z1yGs\n\tfor ; Tue, 21 Apr 2026 18:40:31 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wF6e9-0005bY-HQ; Tue, 21 Apr 2026 04:39:53 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from )\n id 1wF6e7-0005b4-2s\n for qemu-devel@nongnu.org; Tue, 21 Apr 2026 04:39:51 -0400","from mail-yx1-xb12f.google.com ([2607:f8b0:4864:20::b12f])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from )\n id 1wF6e5-0002cP-Ad\n for qemu-devel@nongnu.org; Tue, 21 Apr 2026 04:39:50 -0400","by mail-yx1-xb12f.google.com with SMTP id\n 956f58d0204a3-65006c99d38so3724824d50.3\n for ; Tue, 21 Apr 2026 01:39:48 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; t=1776760788; cv=none;\n d=google.com; s=arc-20240605;\n b=C9WHoLXT2ysmJYZJB9IL0OeErv2NhRnljpj8PwFAnuVxKPD0bAkLjm1gl7qfy4x1oq\n wBKHwBSFZnATPZpNok89I8i4bGsZpWQjm5vsJsVikTrekv41nw8glRcjmxFuPou5cEkI\n PZ+YVsdAXFAkkRFJudEV9RznVszQ1tN3wnb4ZpMRoXjF1USZVFxU+Id7fXks5diYPjO9\n XMGu2zr098aoyOaJjbFeChExKKywO5VtfuW2nrRnTU1IAWIbNeey2zv6yI7Qef5Ufswd\n v5yFAiFFlsf2gm1Veh3lVo9kSG1qJqW35Hzg4bqe7gJsYBp64ZpcTcNHshah4QJG2Hjz\n yCkQ==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=WkrkKEPiE6o76ppNllO7Kkip67JjPVL/dOUbpu/tdUs=;\n fh=QzDfVTax6L6UX9hyN03AjD8AX423EV4qQK2O5I2vHx0=;\n b=W2aDIgMtbU/+5IVZ8Xrmme7FqlMUQuB5DfmnvFcLjkCaZ2FbGqt6sQC6h50ZLJeZrU\n gVIa2D3hUAqfmr87B2vyhDhtOaV8kG//bshBURerDUVC79uJuu0wFUZdQBCqBVnCdFhU\n 6McMzXW5isfl7Y4X0h7J+BeLq9Ivz8IgqkbJTbHArV8NY7261oe7V+7Jzu6HHALR7USr\n dml2Pvbsv/hgkjbHEVGooAQ5qS56kQED/kb3vb9Tb5C4fP9AIDGV8xKdn5N9GECC3Hsm\n 38KvNZjJLnebR37fLxustHrvr/6qTLakqRyaqPQRWPdXYfkPOcaxwBM+bLjk+mDvdVQp\n kOPw==; darn=nongnu.org","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776760788; x=1777365588; darn=nongnu.org;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=WkrkKEPiE6o76ppNllO7Kkip67JjPVL/dOUbpu/tdUs=;\n b=yVGClDDKEfbjAOBJtcrGj2kr7A8j0u1seCXcwxniNiVy0sb7lJJmg2VC18xDm1Xxnx\n Lw7Kir4ithU99Y1EiylSToklvuPNLChopdebmL1btT8laXQVdSLvJtcccvEnD4o1o8ds\n r5N4TWGBZaJF2ncJRyF+X/9ITWPzOehvA4qUZgJCxYRTssJ0bfYAXgSCra51FjkxnA8c\n lEnnL265uV/VNiHTgZYeZEmESLWFhwL2zKGcMGcsusteURv9XpBaoA02XennmmrChyfd\n 73Qvlw/V2vhxQAx+fNdG450F2f+yrGbdSsMw9DszLB7KwHC1CSxfXz2/LQ/TOKfb9yIq\n D+LA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776760788; x=1777365588;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=WkrkKEPiE6o76ppNllO7Kkip67JjPVL/dOUbpu/tdUs=;\n b=X6gAfPGfXTwaWR7nvqIuraaKBwN3x/CiqFm74yeaktB3ikA7/TbMtBtvhh22jif8Uu\n wL+Jz5Vpuyz0uI8Mu5Ou8YBTh1wLr6ojF+MPZM+KCCl7HWJ0OiIgMWQty5izJrjettHc\n 90cO+9FoQkkgoVJfgINvC8fc1XStItGUKn/qQkyOw210434jcT71o2l/iO3OsHtQFPRV\n 0hVwsJxzcn7qU1476NCmvxyRJkSH+Lh7zzGvgSgOq2yEBw4dYv33k6Rox6kROHlRIXZh\n DaWU8cWpHVpLB4zQfAVdW2fSjCVEGhI5cav/JTB5GcGfbhPzNYLv78gmPenPGR+pSkyp\n Umgg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ9k2xxOKsB2H4/Ics4heUDAtBtfdarEeF5QITJviFQxL5Ix3nibNHXIJGZpFoIzZ8waoL6bi39nX4SJ@nongnu.org","X-Gm-Message-State":"AOJu0Yw0Yiqd2ICsJeMkk7yQsosMMqcvdlknDB45pj/aMiYxfsqxM/hr\n GVZIe/8Xc/fnIFqGFqrsN5/btNpcl6JcPo6p5/6Y4hs2krsgrgl5iS2RYcnPVEnMrMfaBaO125j\n u2iXhs53MYy9ncyVvXwccqhS/mjrfkckcTE/WLGe6bQ==","X-Gm-Gg":"AeBDietYNjmd4Fn5CX6jtl9qbLxOMc3zcPqLUkrdKWbCq9/7mgWhDC0Pm63V73ZUesV\n +jFmkRC6dX6o1ltO+z0TCJBGrw/84tQ2QOU07siOxZwX90puV6+k4oK/mijTTVbOnfYGQYV0qTi\n cbeT11hn/1BllF6w0CczoCerl2Um3GmdiyHYbCVPtCqnx4OSUYXl6N6RE5okmLLaaVDeiaAKacp\n ugs6p65vv3HrBsSSqC9cnT7VxzEfSdJqtb8O8dPETOTexYxLhyMXTOvMrmRQjIFQQ8f5zj1c69c\n iTMuqMJJPQeT893Jt+bgZHK/yAdhYiVeNAM2kGLehrlTF7tLOi05GZY3yWGFouceyFiGB+iV5lX\n 4st4ho4Yfsp+K","X-Received":"by 2002:a05:690e:488a:b0:651:c53a:ffd9 with SMTP id\n 956f58d0204a3-65310b30793mr11274024d50.56.1776760787606; Tue, 21 Apr 2026\n 01:39:47 -0700 (PDT)","MIME-Version":"1.0","References":"<20260420075159.106615-1-thuth@redhat.com>\n \n ","In-Reply-To":"","From":"Peter Maydell ","Date":"Tue, 21 Apr 2026 09:39:35 +0100","X-Gm-Features":"AQROBzBPXVmt-bpotCgiLVYfcQhAz6hJceupW-2L-TVIw1PY3Hwh-Q40GanMIdc","Message-ID":"\n ","Subject":"Re: [PATCH] system/memory: Don't call MR handlers for bytes beyond\n the MR's size","To":"Thomas Huth ","Cc":"Paolo Bonzini , Peter Xu ,\n qemu-devel@nongnu.org,\n =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ","Content-Type":"text/plain; charset=\"UTF-8\"","Received-SPF":"pass client-ip=2607:f8b0:4864:20::b12f;\n envelope-from=peter.maydell@linaro.org; helo=mail-yx1-xb12f.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]