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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5C1BEC3DA6E for ; Fri, 5 Jan 2024 20:43:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=L9ndNZyyxVVwxUAXRtJtPz2OAJj2XjaP1udbp7dgv30=; b=Uot/M2IxBmCN97 4pUFJAS6udN9bKZGymqrUAFFmzvInd8lKy7SdC6IrhNlCvFAQH9vX5g1e10ZKEyMSAg6ckvR3Uj4t RMBMBYn1pIW0Ye3RJ+YOJPACh9gmcwNF+/JowCYIhsgcvFCSP1RUWMTizFli7QBNTPLPBY9GXCS2E QKSomPl3ZollG+BFCbbkh+tvusSwcVJMAnBi5aViOrk3pz6Trv5B/+/oGmiCyK3//gr6EXW06vL7k 69HcFRTkQALXk+/VHyzexr4cOSwJkfao8f9N1Xu4+M3F8j5IJ87ruW26UYZ0x1cvA4BzAJXpSDzUA dWws6ofp/T8dAE0Nj1kw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rLr1k-000E0Z-20; Fri, 05 Jan 2024 20:42:48 +0000 Received: from out-183.mta0.migadu.com ([91.218.175.183]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rLr1g-000Dyu-1D for linux-arm-kernel@lists.infradead.org; Fri, 05 Jan 2024 20:42:46 +0000 Date: Fri, 5 Jan 2024 20:42:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1704487358; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YIgLwiupop3bcxFtQ1AH4pX9ofQaPh7Mzpc0S80SOXs=; b=XqyiIYzjEWK+lm3UJXl+Vepjb6r75wBWBi9XIOu99PHz4UoyFsf5hyJcpiTvig2PFZqfAa S8QYTaVvSX4WXvUncN3E9CeUPUh98X6eDHybtqCe7gwZPwEYwS8ILIbBFbc0Oq3mJLVPqB H5ExmHtEKBIoIc+f2+qjmPXgY/QWakI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Catalin Marinas Cc: Lorenzo Pieralisi , Jason Gunthorpe , ankita@nvidia.com, maz@kernel.org, suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org, alex.williamson@redhat.com, kevin.tian@intel.com, yi.l.liu@intel.com, ardb@kernel.org, akpm@linux-foundation.org, gshan@redhat.com, linux-mm@kvack.org, aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com, targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com, apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com, mochs@nvidia.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com Subject: Re: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices Message-ID: References: <20231208164709.23101-1-ankita@nvidia.com> <20231208164709.23101-3-ankita@nvidia.com> <20231212181156.GO3014157@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240105_124244_842880_E404D12A X-CRM114-Status: GOOD ( 21.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Dec 21, 2023 at 01:19:18PM +0000, Catalin Marinas wrote: [...] > > Apologies, I didn't mean to question what's going on here from the > > hardware POV. My concern was more from the kernel + user interfaces POV, > > this all seems to work (specifically for PCI) by maintaining an > > intentional mismatch between the VFIO stage-1 and KVM stage-2 mappings. > > If you stare at it long enough, the mismatch starts to look fine ;). > Even if you have the VFIO stage 1 Normal NC, KVM stage 2 Normal NC, you > can still have the guest setting stage 1 to Device and introduce an > architectural mismatch. These aliases have some bad reputation but the > behaviour is constrained architecturally. > > IMHO we should move on from this attribute mismatch since we can't fully > solve it anyway and focus instead on what the device, system can > tolerate, who's responsible for deciding which MMIO ranges can be mapped > as Normal NC. Fair enough :) The other slightly unsavory part is that we're baking the mapping policy into KVM. I'd prefer it if this policy were kept in userspace somehow, but there's no actual usecase for userspace selecting memory attributes at this point. > If we really want to avoid any aliases (though I think we are spending > too many cycles on something that's not a real issue), the only way is > to have fd-based mappings in KVM so that there's no VMM alias. After > that we need to choose between (2) and (3) since the VMM may no longer > be able to probe the device and figure out which ranges need what > attributes. These are the sorts of things I was more worried about. I completely agree that the patches are fine for relaxing the 'simple' PCIe use cases, I just don't want to establish the precedent that the kernel/KVM will be on the hook to work out more complex use cases that may require the composition of various mappings. But I'm happy to table that discussion until the usecase arises :) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel