From patchwork Sat Oct 21 11:24:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: BALATON Zoltan X-Patchwork-Id: 828927 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3yK2Q11Dg5z9t2t for ; Sat, 21 Oct 2017 23:43:00 +1100 (AEDT) Received: from localhost ([::1]:57764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5t74-0006Xx-J1 for incoming@patchwork.ozlabs.org; Sat, 21 Oct 2017 08:42:50 -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+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 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 0000000000000000-000000000000ffff address-space: I/O 0000000000000000-000000000000ffff (prio 0, i/o): io 0000000000001000-0000000000001007 (prio 1, i/o): alias sii3112.bar0 @sii3112.bar5 0000000000000080-0000000000000087 0000000000001008-000000000000100b (prio 1, i/o): alias sii3112.bar1 @sii3112.bar5 0000000000000088-000000000000008b 0000000000001010-0000000000001017 (prio 1, i/o): alias sii3112.bar2 @sii3112.bar5 00000000000000c0-00000000000000c7 0000000000001018-000000000000101b (prio 1, i/o): alias sii3112.bar3 @sii3112.bar5 00000000000000c8-00000000000000cb 0000000000001020-000000000000102f (prio 1, i/o): alias sii3112.bar4 @sii3112.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 MemoryRegionSection *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); }