From nobody Sun Nov 2 00:52:32 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 150858982385379.94974907485425; Sat, 21 Oct 2017 05:43:43 -0700 (PDT) Received: from localhost ([::1]:57765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5t7a-0006q0-CZ for importer@patchew.org; Sat, 21 Oct 2017 08:43:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5t6f-0006Xs-V2 for qemu-devel@nongnu.org; Sat, 21 Oct 2017 08:42:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5t6c-0000az-Sy for qemu-devel@nongnu.org; Sat, 21 Oct 2017 08:42:26 -0400 Received: from zero.eik.bme.hu ([152.66.115.2]:11559) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e5t6c-0000Y9-HZ for qemu-devel@nongnu.org; Sat, 21 Oct 2017 08:42:22 -0400 Received: from zero.eik.bme.hu (blah.eik.bme.hu [152.66.115.182]) by localhost (Postfix) with SMTP id B500E7456F6; Sat, 21 Oct 2017 14:42:13 +0200 (CEST) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 84AEC7456EF; Sat, 21 Oct 2017 14:42:13 +0200 (CEST) From: BALATON Zoltan Date: Sat, 21 Oct 2017 13:24:51 +0200 To: qemu-devel@nongnu.org Message-Id: <20171021124213.84AEC7456EF@zero.eik.bme.hu> X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 152.66.115.2 Subject: [Qemu-devel] [PATCH] exec: Fix section_covers_addr() for sections with non-zero offset X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Paolo Bonzini , Richard Henderson , Fam Zheng , Peter Crosthwaite Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" When a section with non-0 offset_within_region field is tested to cover an address the offset should be taken into account as well. This fixes a crash caused by picking the wrong memory region in address_space_lookup_region seen with client code accessing a device model that uses alias memory regions. Signed-off-by: BALATON Zoltan --- This seems to fix the problem described in http://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg03356.html but I'm not completely sure about it. This seems to be introduced in 729633c exec: Introduce AddressSpaceDispatch.mru_section and the patch before that which split off section_covers_addr from phys_page_find so this patch also changes that caller. Is that OK to do? It appears to work but I don't know this part of QEMU. Also the bug seems to be caused by section_covers_addr accepting sii3112.bar5 when that's the mru_section instead of picking sii3112.bar0 (which it picks when going through phys_page_find) when client code is accessing 0xc08001006 from this address map (full address map is at above URL): address-space: memory 0000000c08000000-0000000c0800ffff (prio 0, i/o): alias isa_mmio @io 000= 0000000000000-000000000000ffff address-space: I/O 0000000000000000-000000000000ffff (prio 0, i/o): io 0000000000001000-0000000000001007 (prio 1, i/o): alias sii3112.bar0 @si= i3112.bar5 0000000000000080-0000000000000087 0000000000001008-000000000000100b (prio 1, i/o): alias sii3112.bar1 @si= i3112.bar5 0000000000000088-000000000000008b 0000000000001010-0000000000001017 (prio 1, i/o): alias sii3112.bar2 @si= i3112.bar5 00000000000000c0-00000000000000c7 0000000000001018-000000000000101b (prio 1, i/o): alias sii3112.bar3 @si= i3112.bar5 00000000000000c8-00000000000000cb 0000000000001020-000000000000102f (prio 1, i/o): alias sii3112.bar4 @si= i3112.bar5 0000000000000000-000000000000000f which this patch fixes but would the same problem happen if the mru_section is bar5 but bar4 is accessed? I could not reproduce that case but then the offset is 0 but in this case the address would be above 0xc08001020 and size is 0xf so they probably won't match. But this is only because of the size of the region. Could that mean the bug is caused by something else and should be fixed elsewhere? --- exec.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/exec.c b/exec.c index db5ae23..a915817 100644 --- a/exec.c +++ b/exec.c @@ -370,7 +370,8 @@ static inline bool section_covers_addr(const MemoryRegi= onSection *section, * the section must cover the entire address space. */ return int128_gethi(section->size) || - range_covers_byte(section->offset_within_address_space, + range_covers_byte(section->offset_within_address_space + + section->offset_within_region, int128_getlo(section->size), addr); } =20 --=20 2.7.6