From patchwork Thu Jan 16 04:44:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 311561 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)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 923FD2C0079 for ; Thu, 16 Jan 2014 15:44:44 +1100 (EST) Received: from localhost ([::1]:58362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3eor-00009a-R2 for incoming@patchwork.ozlabs.org; Wed, 15 Jan 2014 23:44:41 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3eoZ-0008Qr-DZ for qemu-devel@nongnu.org; Wed, 15 Jan 2014 23:44:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3eoT-0004Xr-E0 for qemu-devel@nongnu.org; Wed, 15 Jan 2014 23:44:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3eoT-0004Xn-76 for qemu-devel@nongnu.org; Wed, 15 Jan 2014 23:44:17 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0G4iFuM017003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Jan 2014 23:44:15 -0500 Received: from bling.home ([10.3.113.17]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s0G4iENX001890; Wed, 15 Jan 2014 23:44:14 -0500 From: Alex Williamson To: alex.williamson@redhat.com Date: Wed, 15 Jan 2014 21:44:14 -0700 Message-ID: <20140116044321.23067.79229.stgit@bling.home> User-Agent: StGit/0.17-dirty MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: aik@ozlabs.ru, bsd@redhat.com, qemu-devel@nongnu.org, mst@redhat.com Subject: [Qemu-devel] [PATCH v2] vfio: Filter out bogus mappings 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 Since 57271d63 we now see spurious mappings with the upper bits set if 64bit PCI BARs are sized while enabled. The guest writes a mask of 0xffffffff to the lower BAR to size it, then restores it, then writes the same mask to the upper BAR resulting in a spurious BAR mapping into the last 4G of the 64bit address space. Most architectures do not support or make use of the full 64bits address space for PCI BARs, so we filter out mappings with the high bit set. Long term, we probably need to think about vfio telling us the address width limitations of the IOMMU. Signed-off-by: Alex Williamson Reviewed-by: Michael S. Tsirkin --- hw/misc/vfio.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c index 30b1a78..d304213 100644 --- a/hw/misc/vfio.c +++ b/hw/misc/vfio.c @@ -2156,7 +2156,14 @@ static int vfio_dma_map(VFIOContainer *container, hwaddr iova, static bool vfio_listener_skipped_section(MemoryRegionSection *section) { - return !memory_region_is_ram(section->mr); + return !memory_region_is_ram(section->mr) || + /* + * Sizing an enabled 64-bit BAR can cause spurious mappings to + * addresses in the upper part of the 64-bit address space. These + * are never accessed by the CPU and beyond the address width of + * some IOMMU hardware. TODO: VFIO should tell us the IOMMU width. + */ + section->offset_within_address_space & (1ULL << 63); } static void vfio_listener_region_add(MemoryListener *listener,