From patchwork Wed Nov 6 22:09:50 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcel Apfelbaum X-Patchwork-Id: 289036 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 708AE2C00D1 for ; Thu, 7 Nov 2013 09:13:12 +1100 (EST) Received: from localhost ([::1]:36281 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeBLU-000146-HV for incoming@patchwork.ozlabs.org; Wed, 06 Nov 2013 17:13:04 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeBL7-00013W-3v for qemu-devel@nongnu.org; Wed, 06 Nov 2013 17:12:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VeBL1-0007bG-4f for qemu-devel@nongnu.org; Wed, 06 Nov 2013 17:12:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeBL0-0007bA-SS for qemu-devel@nongnu.org; Wed, 06 Nov 2013 17:12:35 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA6MCYqT015526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Nov 2013 17:12:34 -0500 Received: from [10.35.200.52] (vpn-200-52.tlv.redhat.com [10.35.200.52]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rA6MCVP5016417; Wed, 6 Nov 2013 17:12:32 -0500 Message-ID: <1383775790.2527.41.camel@localhost.localdomain> From: Marcel Apfelbaum To: "Michael S. Tsirkin" Date: Thu, 07 Nov 2013 00:09:50 +0200 In-Reply-To: <20131106201358.GA21997@redhat.com> References: <1383763674-18374-1-git-send-email-mst@redhat.com> <1383767643.2527.38.camel@localhost.localdomain> <20131106201358.GA21997@redhat.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com Subject: Re: [Qemu-devel] [PATCH for-1.7 0/5] fix address space size issues X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Wed, 2013-11-06 at 22:13 +0200, Michael S. Tsirkin wrote: > On Wed, Nov 06, 2013 at 09:54:03PM +0200, Marcel Apfelbaum wrote: > > On Wed, 2013-11-06 at 20:47 +0200, Michael S. Tsirkin wrote: > > > A bug reported by Luiz Capitulino let us to find > > > several bugs in memory address space setup. > > > > > > One issue is that gdb stub can give us arbitrary addresses > > > and we'll try to access them. > > > Since our lookup ignored high bits in the address, > > > we hit a wrong section and got a crash. > > > In fact, PCI devices can access arbitrary addresses too, > > > so we should just make lookup robust against this case. > > > > > > Another issue has to do with size of regions. > > > memory API uses UINT64_MAX so say "all 64 bit" but > > > some devices mistakenly used INT64_MAX. > > > > > > It should not affect most systems in practice as > > > everything should be limited by address space size, > > > but it's an API misuse that we should not keep around, > > > and it will become a problem if a system with 64 bit > > > target address hits this path. > > > > > > Patch 1 fixes an actual bug. > > > The rest of patches make code cleaner and more robust. > > > > > > Michael S. Tsirkin (4): > > > exec: don't ignore high address bits on lookup > > > pci: fix address space size for bridge > > > exec: don't ignore high address bits on set > > > spapr_pci: s/INT64_MAX/UINT64_MAX/ > > > > > > Paolo Bonzini (1): > > > pc: s/INT64_MAX/UINT64_MAX/ > > > > > > exec.c | 9 +++++++++ > > > hw/i386/pc_piix.c | 2 +- > > > hw/i386/pc_q35.c | 2 +- > > > hw/pci/pci_bridge.c | 2 +- > > > hw/ppc/spapr_pci.c | 2 +- > > > 5 files changed, 13 insertions(+), 4 deletions(-) > > > > > > > Reviewed-by: Marcel Apfelbaum > > > > Please don't apply this. > > I didn't post the patches - I only sent them to Marcel :) > And the reason is that the assert in exec. detects more bugs with > over-writing page-tables: just run make check. > > I think we need to get a handle on them first before applying. > Found the issues with make check, so that this series can be posted. I'll send a proper patch tomorrow: Thanks, Marcel diff --git a/hw/alpha/typhoon.c b/hw/alpha/typhoon.c index 59e1bb8..c203935 100644 --- a/hw/alpha/typhoon.c +++ b/hw/alpha/typhoon.c @@ -888,7 +888,8 @@ PCIBus *typhoon_init(ram_addr_t ram_size, ISABus **isa_bus, /* Host memory as seen from the PCI side, via the IOMMU. */ memory_region_init_iommu(&s->pchip.iommu, OBJECT(s), &typhoon_iommu_ops, - "iommu-typhoon", UINT64_MAX); + "iommu-typhoon", TARGET_PHYS_ADDR_SPACE_BITS == 64 ? + UINT64_MAX : (0x1ULL << TARGET_PHYS_ADDR_SPACE_BITS)); address_space_init(&s->pchip.iommu_as, &s->pchip.iommu, "pchip0-pci"); pci_setup_iommu(b, typhoon_pci_dma_iommu, s); diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c index ef45f4f..84b1309 100644 --- a/hw/ppc/spapr_iommu.c +++ b/hw/ppc/spapr_iommu.c @@ -136,7 +136,9 @@ static int spapr_tce_table_realize(DeviceState *dev) trace_spapr_iommu_new_table(tcet->liobn, tcet, tcet->table, tcet->fd); memory_region_init_iommu(&tcet->iommu, OBJECT(dev), &spapr_iommu_ops, - "iommu-spapr", UINT64_MAX); + "iommu-spapr", + TARGET_PHYS_ADDR_SPACE_BITS == 64 ? + UINT64_MAX : (0x1ULL << TARGET_PHYS_ADDR_SPACE_BITS)); QLIST_INSERT_HEAD(&spapr_tce_tables, tcet, list);