From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10A8FC4743C for ; Wed, 23 Jun 2021 07:43:28 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 870CC611AC for ; Wed, 23 Jun 2021 07:43:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 870CC611AC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dme.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:49956 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvxXi-00083r-F7 for qemu-devel@archiver.kernel.org; Wed, 23 Jun 2021 03:43:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50832) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvxVk-0007Lw-QD for qemu-devel@nongnu.org; Wed, 23 Jun 2021 03:41:24 -0400 Received: from forward4-smtp.messagingengine.com ([66.111.4.238]:53703) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvxVO-0000S5-Cu for qemu-devel@nongnu.org; Wed, 23 Jun 2021 03:41:23 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.nyi.internal (Postfix) with ESMTP id 7845D1940103; Wed, 23 Jun 2021 03:41:00 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 23 Jun 2021 03:41:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jKOUFs bKIVhOYWb3QMgMw9Xa5cRcHv5EON5binuPcB0=; b=P2ENYL/0VvxLS8gRKjGuQQ 6Akcrqm+akO8XOUqH2cDjFUuX+Ov+TmuLVfJyVcVw0zjdp0Rtdtkt9egvLfcsCjo pdQaDrlYqYlceMNYODUGTRTTknwZAX7ncsWuGg5Eq8eBKlrxvunvcDGOVr23JAC5 LTT07Nt5+HuJZRdcoKskjf6KILL/P6EWGUtLd/HOATLRfZ81cqcbvWsNFQevp5/l ufelRd8QXrWsz7CP7aaROoeybFQbQhcQrwJgEtyvl7nGwyuXOrd6wzuPFdOV5tYU lXJDUT0a9BgoSkdSuBA1R+dlwP/CnHZmH1aTecJ3Al67+rXdHzSDcUvgfXL8WYBA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegvddguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefvufgjfhfhfffkgggtsehttdertddttddtnecuhfhrohhmpeffrghvihgu ucfgughmohhnughsohhnuceoughmvgesughmvgdrohhrgheqnecuggftrfgrthhtvghrnh ephfekgeeutddvgeffffetheejvdejieetgfefgfffudegffffgeduheegteegleeknecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmvgesug hmvgdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Jun 2021 03:40:59 -0400 (EDT) Received: from localhost (disaster-area.hh.sledj.net [local]) by disaster-area.hh.sledj.net (OpenSMTPD) with ESMTPA id 98472098; Wed, 23 Jun 2021 07:40:55 +0000 (UTC) To: Alex Williamson , Joao Martins Subject: Re: [PATCH RFC 0/6] i386/pc: Fix creation of >= 1Tb guests on AMD systems with IOMMU In-Reply-To: <20210622151629.6c75427c.alex.williamson@redhat.com> References: <20210622154905.30858-1-joao.m.martins@oracle.com> <20210622151629.6c75427c.alex.williamson@redhat.com> X-HGTTG: fertle From: David Edmondson Date: Wed, 23 Jun 2021 08:40:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: neutral client-ip=66.111.4.238; envelope-from=dme@dme.org; helo=forward4-smtp.messagingengine.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , "Michael S . Tsirkin" , Richard Henderson , qemu-devel@nongnu.org, Daniel Jordan , Auger Eric , Suravee Suthikulpanit , Igor Mammedov , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tuesday, 2021-06-22 at 15:16:29 -06, Alex Williamson wrote: >> Additionally, an alternative to hardcoded ranges as we do today, >> VFIO could advertise the platform valid IOVA ranges without necessarily >> requiring to have a PCI device added in the vfio container. That would >> fetching the valid IOVA ranges from VFIO, rather than hardcoded IOVA >> ranges as we do today. But sadly, wouldn't work for older hypervisors. > > > $ grep -h . /sys/kernel/iommu_groups/*/reserved_regions | sort -u > 0x00000000fee00000 0x00000000feefffff msi > 0x000000fd00000000 0x000000ffffffffff reserved > > Ideally we might take that into account on all hosts, but of course > then we run into massive compatibility issues when we consider > migration. We run into similar problems when people try to assign > devices to non-x86 TCG hosts, where the arch doesn't have a natural > memory hole overlapping the msi range. > > The issue here is similar to trying to find a set of supported CPU > flags across hosts, QEMU only has visibility to the host where it runs, > an upper level tool needs to be able to pass through information about > compatibility to all possible migration targets. Towards that end, we > should probably have command line options that either allow to specify > specific usable or reserved GPA address ranges. For example something > like: > --reserved-mem-ranges=host > > Or explicitly: > > --reserved-mem-ranges=13G@1010G,1M@4078M Would this not naturally be a property of a machine model? dme. -- Seems I'm not alone at being alone.