Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp4806805rdb; Tue, 12 Dec 2023 09:47:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IEpdw0YgL9vwBE8gM43cX3xph5UX+03YctcgqOjGOD6Xrjdts2hZ4b3PLBBgip0qSuf0IFr X-Received: by 2002:a05:6a00:1248:b0:6ce:5373:96c9 with SMTP id u8-20020a056a00124800b006ce537396c9mr3845715pfi.40.1702403221800; Tue, 12 Dec 2023 09:47:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702403221; cv=none; d=google.com; s=arc-20160816; b=An2f+FxBxHP47h8keyEbpAvhXgIUB/mBJgcg8quJkPzbODBfqF/cj4/j2psx/RYMes g3K4i+disYhP57oRJctkiiAX9PMRkHuY+V3nJdaGfn0lqp3RWeB61bc9c4Rn5tDhEqdE AkKmY1BsOVOqGeLep2cZc0NXPZktAWWAbbsXPK/zopxthctBK2WXiaaNDDQOvcqjrLYR 2pDV4cs/kI+82i0pETSaY4sE0pO6lDRIPWIkqJmTLUP8YfQRn4U/U2DUvMTC92lPiNfV OcQg5NVODkhLloKjXYdrGyPPg72iS2ISgxpGhflI59efd7SDTNyB0EpHCuqKlyr3qSeM /Plw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=wiNjlUGFThPC9Ue9cHngMXX8jYRGUAqxP5oKJPff5cg=; fh=WhxzlHWRn4+iJ51THhMoC5frG09B2KaLaG2tLbMOG2g=; b=FJMcdCrR5qTqC/EdvCciODq7mrStcOf/GS033Q+U/XY+i4Ifau0wOQ0Rj63hVahyKr qWrF+9M7ahCbXSQKYXBQpKje96tj1RiyToW4noZc4bgBc53QLpsU7sDMSOiE2AOhAgGt /i97xTFtS+OjoimCzDe6rJzRgmU/T4LqbHJeTjtFWDIuWpy9EdR9xLDozcLn4kcvtnl8 8RqqJcZcfPqmnpajn4gE+6TjURzkoj64aOvcJat5h0cXM/vzMdHPTo81Sa31KODCxur2 AQAzbh5yDL8xRcvgUGOKcBlouc5VRUUqm7MVGW6+V9+ATfFlcKo2e1CiZPZhfRirPNRD Ydww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id z11-20020aa7888b000000b006ceb1a0fa60si8143713pfe.8.2023.12.12.09.47.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 09:47:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id D7E8D8051ABE; Tue, 12 Dec 2023 09:46:58 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232817AbjLLRqg (ORCPT + 99 others); Tue, 12 Dec 2023 12:46:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230181AbjLLRqf (ORCPT ); Tue, 12 Dec 2023 12:46:35 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 909F494 for ; Tue, 12 Dec 2023 09:46:41 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60BECC433C8; Tue, 12 Dec 2023 17:46:36 +0000 (UTC) Date: Tue, 12 Dec 2023 17:46:34 +0000 From: Catalin Marinas To: ankita@nvidia.com Cc: jgg@nvidia.com, maz@kernel.org, oliver.upton@linux.dev, 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, lpieralisi@kernel.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 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231208164709.23101-3-ankita@nvidia.com> X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 12 Dec 2023 09:46:59 -0800 (PST) On Fri, Dec 08, 2023 at 10:17:09PM +0530, ankita@nvidia.com wrote: > arch/arm64/kvm/hyp/pgtable.c | 3 +++ > arch/arm64/kvm/mmu.c | 16 +++++++++++++--- > drivers/vfio/pci/vfio_pci_core.c | 3 ++- > include/linux/mm.h | 7 +++++++ > 4 files changed, 25 insertions(+), 4 deletions(-) It might be worth factoring out the vfio bits into a separate patch together with a bit of documentation around this new vma flag (up to Alex really). > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > index d4835d553c61..c8696c9e7a60 100644 > --- a/arch/arm64/kvm/hyp/pgtable.c > +++ b/arch/arm64/kvm/hyp/pgtable.c > @@ -722,6 +722,9 @@ static int stage2_set_prot_attr(struct kvm_pgtable *pgt, enum kvm_pgtable_prot p > kvm_pte_t attr; > u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS; > > + if (device && normal_nc) > + return -EINVAL; Ah, the comment Will and I made on patch 1 is handled here. Add a WARN_ON_ONCE() and please move this hunk to the first patch, it makes more sense there. > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index d14504821b79..1ce1b6d89bf9 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -1381,7 +1381,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > int ret = 0; > bool write_fault, writable, force_pte = false; > bool exec_fault, mte_allowed; > - bool device = false; > + bool device = false, vfio_pci_device = false; I don't think the variable here should be named vfio_pci_device, the VM_* flag doesn't mention PCI. So just something like "vfio_allow_wc". > unsigned long mmu_seq; > struct kvm *kvm = vcpu->kvm; > struct kvm_mmu_memory_cache *memcache = &vcpu->arch.mmu_page_cache; > @@ -1472,6 +1472,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > gfn = fault_ipa >> PAGE_SHIFT; > mte_allowed = kvm_vma_mte_allowed(vma); > > + vfio_pci_device = !!(vma->vm_flags & VM_VFIO_ALLOW_WC); Nitpick: no need for !!, you are assigning to a bool variable already. > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c > index 1cbc990d42e0..c3f95ec7fc3a 100644 > --- a/drivers/vfio/pci/vfio_pci_core.c > +++ b/drivers/vfio/pci/vfio_pci_core.c > @@ -1863,7 +1863,8 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma > * See remap_pfn_range(), called from vfio_pci_fault() but we can't > * change vm_flags within the fault handler. Set them now. > */ > - vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP); > + vm_flags_set(vma, VM_VFIO_ALLOW_WC | VM_IO | VM_PFNMAP | > + VM_DONTEXPAND | VM_DONTDUMP); Please add a comment here that write-combining is allowed to be enabled by the arch (KVM) code but the default user mmap() will still use pgprot_noncached(). > vma->vm_ops = &vfio_pci_mmap_ops; > > return 0; > diff --git a/include/linux/mm.h b/include/linux/mm.h > index a422cc123a2d..8d3c4820c492 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -391,6 +391,13 @@ extern unsigned int kobjsize(const void *objp); > # define VM_UFFD_MINOR VM_NONE > #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */ > > +#ifdef CONFIG_64BIT > +#define VM_VFIO_ALLOW_WC_BIT 39 /* Convey KVM to map S2 NORMAL_NC */ This comment shouldn't be in the core header file. It knows nothing about S2 and Normal-NC, that's arm64 terminology. You can mention something like VFIO can use this flag hint that write-combining is allowed. > +#define VM_VFIO_ALLOW_WC BIT(VM_VFIO_ALLOW_WC_BIT) > +#else > +#define VM_VFIO_ALLOW_WC VM_NONE > +#endif And I think we need to add some documentation (is there any VFIO-specific doc) that describes what this flag actually means, what is permitted. For example, arm64 doesn't have write-combining without speculative fetches. So if one adds this flag to a new driver, they should know the implications. There's also an expectation that the actual driver (KVM guests) or maybe later DPDK can choose the safe non-cacheable or write-combine (Linux terminology) attributes for the BAR. -- Catalin