Message ID | 20231208164709.23101-3-ankita@nvidia.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5578806vqy; Fri, 8 Dec 2023 08:48:46 -0800 (PST) X-Google-Smtp-Source: AGHT+IHvtCIEcDNiZnwf4HwLZ4H+9woJU8aCEsdZjaoDZ9GUxiaE/+rPXiBIvqoe2udvwdIawBK4 X-Received: by 2002:a05:6359:7413:b0:170:6eb2:783 with SMTP id va19-20020a056359741300b001706eb20783mr180372rwb.28.1702054126449; Fri, 08 Dec 2023 08:48:46 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1702054126; cv=pass; d=google.com; s=arc-20160816; b=HkwglswPZ8DYKHPFqquYaARmYpiqA9iP2NrerunSzAtjYmv2q1+WeJ7JVHHGNUOzPV L9WdVkOw14LhBI2EWhTfxLxs5UNNOm2p1K20x/+lhKnnK7OaqjUaaGxZlzUFOkNokEbx ROykda/Ew0DJ/Uo3SvveHui6VHdH4JwW3jBsLGODnEbJPza+U5kKipX77CU3kmTzkOfy U/izw6j3FCn9BtzRYTMK8/0+gtBJAokASyH/C8Zh98v3SXcU8KacBplTAcUavB6o/Slj zT2V9K3TzLi0acFmXzy1c7Ec3UpC9B1zqYBJi11wN3lO6/a2L7ErhVP4+aAn2dKn2jJD jDwg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=rdqJ/MqrrTEdlgdPk7gcSIxLY3/h+42UQ3wjWVPBf6Y=; fh=0Tsl44wuFn04iOApd4iF3AzqGoj5T7HzOCC5KxUHaVc=; b=QuBKrUM8hhtrgiQjiikjqsfOyplEjwQr51akFS7QGihqMLLmA1nFNJchNFAA/eT4Xg W+a2Ca38ZRaMErwVlMWaWaYf8AveMjrnvme5ll1DNnSzm1zPAKf3/SN1fpoWyu+9gIy1 imBdr9JEY8MWVpbSgoTxt6hwTSKfdEV9kf7KoTUP2MlkVPp7M44n0wB2hcKkBzSDP+sB DvddLmfEGpidg3p9Xz1jAYFDApgZMCYb6D5pSdn4loa96qt/RGu7qJWEevrOF1jNukNQ w0Wpuy3dLdHLpHVGdQ3svboWV3uBpg2GpR4BmMHx9qveOv87CJLT3R4qEAGHPSxgagMA JsIg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@Nvidia.com header.s=selector2 header.b=pat3+ixb; arc=pass (i=1 spf=pass spfdomain=nvidia.com dmarc=pass fromdomain=nvidia.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=nvidia.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id o2-20020a655202000000b005c65dc887dbsi1692015pgp.557.2023.12.08.08.48.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 08:48:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@Nvidia.com header.s=selector2 header.b=pat3+ixb; arc=pass (i=1 spf=pass spfdomain=nvidia.com dmarc=pass fromdomain=nvidia.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=nvidia.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 72C8280FC15C; Fri, 8 Dec 2023 08:48:43 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233730AbjLHQsD (ORCPT <rfc822;pusanteemu@gmail.com> + 99 others); Fri, 8 Dec 2023 11:48:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233709AbjLHQr6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 8 Dec 2023 11:47:58 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2054.outbound.protection.outlook.com [40.107.212.54]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 262D419A6; Fri, 8 Dec 2023 08:47:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DVwkvQ3sNa+XtS3HPuV+ozAPtjrcsGT0tDdt0aKKgUjYT7du70gvAzhZtt3mvuhEiBk6C5HWLeBBRdM47q2591WRzA8DuOg6Yikk1VZ85SObXU1B7wG1TN3n0H38n+vyY9LZaGV/woO+h1kwA+7su+8BrZJPSHN/ZqgeJyzUFFYwq7zwDt2slSiIy5mJDie6jiiYLkEMn3wugVFVq/sYf8DGstk7KpxyHVa1CTQS/HLBk7X90DctzzRBkVt7V/MEdALDlSYFxrEqko92Q8l8IH9Jn/9x3FgrSo181dLDkWZcwreBZBbxxKwzs15PK8kl8ktUIKtXPcJYQ2pxohMBAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rdqJ/MqrrTEdlgdPk7gcSIxLY3/h+42UQ3wjWVPBf6Y=; b=aGvXsUbEW8hoMixRVh6NOzAdvv/4Z68CIDGZX1nKSbOArYvi70scUqRAmBwWlR2K6PFxTFpiJuZAgXI1XTOx/X03shaCsenwuzg09K829OYUmdPA6Hp1MtcWodOOvf3eZTvcxVuw/ESNJh8+gKh80+KRmLXoQf6mKityl5HfrYiv86Vr0QFOVauNKCG4WJWwrrhOQJLyxvhlRrZEgoa5gQCni4VxnK/caZbp0FEFhgE3Pb/VMMmCB6TUke8nVw+mNYk85yC/gl9k00qV9az/jn/XZfnptqzpW9MrDrwRHrUd95xtHb/GZHpOq42njpMcGhjKWGZqA+G6DnCNbQml6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.117.161) smtp.rcpttodomain=vger.kernel.org smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rdqJ/MqrrTEdlgdPk7gcSIxLY3/h+42UQ3wjWVPBf6Y=; b=pat3+ixbIEBcNdTvxh1twlNEpK7TfZvfJMkS9gDhLnTZsw4WC1PSL+TOMeS0PcCTJ4rx1sDUBIruDr1LFS89Rep3rZkmU9dg3BE+CDX1qfHiyyVZhUFYf1GganKGX7zf90ZWlRVOvjKPWF4l8zKuf3rpV+gUTAGx08jdEm6/HYLN1F6oJbDMIVFamypVhaR4q7mDTXpMWAsXG10keDmHyNBHj8PoqmdJeUoJqxo5SnzVNAtvf+48YNTp2kFp1ZnhPAYo/ITNUuYLe2PiMBdRJybsqT+Gc1M+yFcCaFw6Th4E89jPYccna0qH3tBfK7GokYZbEQ/SRW/GlcA8LWph6g== Received: from PH0PR07CA0110.namprd07.prod.outlook.com (2603:10b6:510:4::25) by MN0PR12MB6103.namprd12.prod.outlook.com (2603:10b6:208:3c9::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7068.27; Fri, 8 Dec 2023 16:47:55 +0000 Received: from SA2PEPF000015CA.namprd03.prod.outlook.com (2603:10b6:510:4:cafe::84) by PH0PR07CA0110.outlook.office365.com (2603:10b6:510:4::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7068.28 via Frontend Transport; Fri, 8 Dec 2023 16:47:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.117.161) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.117.161 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C Received: from mail.nvidia.com (216.228.117.161) by SA2PEPF000015CA.mail.protection.outlook.com (10.167.241.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7068.20 via Frontend Transport; Fri, 8 Dec 2023 16:47:54 +0000 Received: from rnnvmail202.nvidia.com (10.129.68.7) by mail.nvidia.com (10.129.200.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.41; Fri, 8 Dec 2023 08:47:37 -0800 Received: from rnnvmail205.nvidia.com (10.129.68.10) by rnnvmail202.nvidia.com (10.129.68.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.41; Fri, 8 Dec 2023 08:47:36 -0800 Received: from sgarnayak-dt.nvidia.com (10.127.8.9) by mail.nvidia.com (10.129.68.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.41 via Frontend Transport; Fri, 8 Dec 2023 08:47:29 -0800 From: <ankita@nvidia.com> To: <ankita@nvidia.com>, <jgg@nvidia.com>, <maz@kernel.org>, <oliver.upton@linux.dev>, <suzuki.poulose@arm.com>, <yuzenghui@huawei.com>, <catalin.marinas@arm.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> CC: <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: [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices Date: Fri, 8 Dec 2023 22:17:09 +0530 Message-ID: <20231208164709.23101-3-ankita@nvidia.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20231208164709.23101-1-ankita@nvidia.com> References: <20231208164709.23101-1-ankita@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain X-NV-OnPremToCloud: ExternallySecured X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF000015CA:EE_|MN0PR12MB6103:EE_ X-MS-Office365-Filtering-Correlation-Id: b3ed524c-c425-4b36-cc3f-08dbf80d6cb5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5SCtre8fJDGs6Wt81EkObPxcwz6fNsw6HmuOkYhQoQve8Xel+9sE0tJgdTcW70BJsBLcEt/0fvAgiZuYTdrnFDKxRCeVFmBSXwkftncgbOb3qR4zTZ2yGBZQ9PYL3yw1f6ewzJMGm0ePoK4zzYeTQhmLhOrMyeTZvsE8tO9Ru549nU5B8IfGrZDVy39BlZk4jsLw6VuVaijTk5bxKV/194YgGw3AZsrTGLKfec1kNj/x77W8xAOptSBda5NvfBeLO+qsSCK0sL51G4BnQldpjI9CCRms/FqjTfEcg0j/wMvLwhWXtAg+DLC2rRbhsTGwQmVJ8y1OYzXgz/ZXLnb2b6Oi+vz4PNAqMCB5EseqpvwRECQFG0dEnPvDYwZKEwe4E8BmxwIDZAqvfTMUvgSaaDRXzttsTclyMvu02jyiBT/l4Cifglr8WMmMl8w+rLgx2VR0C/sHDJrDKOjxvxI6T2jESHM+Si+ONbqjNPQbSex94hstxRuxe+WCbnGIBYalaSfBHKV60oJQohY8C2h3oyb8jRfZBRLQsOmmDUu69coEGEd80O9PBZ/gcLJ5tZ9VTecwVVHeCdnNhaUrqKX5Fve9zXIdqnlozQFE0FC4tpqlvWwtLSjdYMoy/Ic7VXiK5YIt3c8UAITOozg1CVpckkspHHLl9xvLrOPyXj2kWS7gfbdjVALnCJYtW86GEuj//XlGMvWMoV/DKgvfgDX7/G3E8/wVydmbAKrNeQDCWBDOizBhK8iomqrJqX9DXVgfpfRPQWjWvDbSI5I8dAQ5iBBTx2v7fhtZ6JeKJOO6CSSs3TtlIzCOO+33qDwMTkxtMNhQ793G5PRZmdK2YhxlG81Kh/FPV75lcEidEV0lwX4= X-Forefront-Antispam-Report: CIP:216.228.117.161;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail.nvidia.com;PTR:dc6edge2.nvidia.com;CAT:NONE;SFS:(13230031)(4636009)(136003)(346002)(376002)(396003)(39860400002)(230273577357003)(230173577357003)(230922051799003)(82310400011)(186009)(1800799012)(64100799003)(451199024)(46966006)(36840700001)(40470700004)(2906002)(7416002)(40480700001)(8936002)(4326008)(8676002)(5660300002)(2876002)(316002)(70206006)(70586007)(40460700003)(110136005)(54906003)(47076005)(36860700001)(7636003)(2616005)(1076003)(7696005)(36756003)(26005)(6666004)(336012)(41300700001)(478600001)(82740400003)(83380400001)(426003)(921008)(356005)(86362001)(2101003)(83996005);DIR:OUT;SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2023 16:47:54.3924 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b3ed524c-c425-4b36-cc3f-08dbf80d6cb5 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.161];Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF000015CA.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6103 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Fri, 08 Dec 2023 08:48:43 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784733107817302839 X-GMAIL-MSGID: 1784733107817302839 |
Series |
kvm: arm64: allow vm to select DEVICE_* and
|
|
Commit Message
Ankit Agrawal
Dec. 8, 2023, 4:47 p.m. UTC
From: Ankit Agrawal <ankita@nvidia.com> To provide VM with the ability to get device IO memory with NormalNC property, map device MMIO in KVM for ARM64 at stage2 as NormalNC. Having NormalNC S2 default puts guests in control (based on [1], "Combining stage 1 and stage 2 memory type attributes") of device MMIO regions memory mappings. The rules are summarized below: ([(S1) - stage1], [(S2) - stage 2]) S1 | S2 | Result NORMAL-WB | NORMAL-NC | NORMAL-NC NORMAL-WT | NORMAL-NC | NORMAL-NC NORMAL-NC | NORMAL-NC | NORMAL-NC DEVICE<attr> | NORMAL-NC | DEVICE<attr> Generalizing this to non PCI devices may be problematic. E.g. GICv2 vCPU interface, which is effectively a shared peripheral, can allow a guest to affect another guest's interrupt distribution. The issue may be solved by limiting the relaxation to mappings that have a user VMA. Still There is insufficient information and uncertainity in the behavior of non PCI driver. Hence caution is maintained and the change is restricted to the VFIO-PCI devices. PCIe on the other hand is safe because the PCI bridge does not generate errors, and thus do not cause uncontained failures. Limiting to the VFIO PCI module is done with the help of a new mm flag VM_VFIO_ALLOW_WC. The VFIO PCI core module set this flag to communicate to KVM. KVM use this flag to activate the code. This could be extended to other devices in the future once that is deemed safe. [1] section D8.5.5 of DDI0487J_a_a-profile_architecture_reference_manual.pdf Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Ankit Agrawal <ankita@nvidia.com> --- 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(-)
Comments
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.
On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote: > > 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. Let's write a comment down here to address both remarks: This flag is used to connect VFIO to arch specific KVM code. It indicates that the memory under this VMA is safe for use with any non-cachable memory type inside KVM. Some VFIO devices, on some platforms, are thought to be unsafe and can cause machine crashes if KVM does not lock down the memory type. > 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. DPDK won't rely on this interface Thanks, Jason
Hi, Sorry, a bit late to the discussion :) On Tue, Dec 12, 2023 at 02:11:56PM -0400, Jason Gunthorpe wrote: > On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote: > > 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. > > DPDK won't rely on this interface Wait, so what's the expected interface for determining the memory attributes at stage-1? I'm somewhat concerned that we're conflating two things here: 1) KVM needs to know the memory attributes to use at stage-2, which isn't fundamentally different from what's needed for userspace stage-1 mappings. 2) KVM additionally needs a hint that the device / VFIO can handle mismatched aliases w/o the machine exploding. This goes beyond supporting Normal-NC mappings at stage-2 and is really a bug with our current scheme (nGnRnE at stage-1, nGnRE at stage-2). I was hoping that (1) could be some 'common' plumbing for both userspace and KVM mappings. And for (2), any case where a device is intolerant of mismatches && KVM cannot force the memory attributes should be rejected. AFAICT, the only reason PCI devices can get the blanket treatment of Normal-NC at stage-2 is because userspace has a Device-* mapping and can't speculatively load from the alias. This feels a bit hacky, and maybe we should prioritize an interface for mapping a device into a VM w/o a valid userspace mapping. I very much understand that this has been going on for a while, and we need to do *something* to get passthrough working well for devices that like 'WC'. I just want to make sure we don't paint ourselves into a corner that's hard to get out of in the future.
[+James] On Wed, Dec 13, 2023 at 08:05:29PM +0000, Oliver Upton wrote: > Hi, > > Sorry, a bit late to the discussion :) > > On Tue, Dec 12, 2023 at 02:11:56PM -0400, Jason Gunthorpe wrote: > > On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote: > > > 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. > > > > DPDK won't rely on this interface > > Wait, so what's the expected interface for determining the memory > attributes at stage-1? I'm somewhat concerned that we're conflating two > things here: > > 1) KVM needs to know the memory attributes to use at stage-2, which > isn't fundamentally different from what's needed for userspace > stage-1 mappings. > > 2) KVM additionally needs a hint that the device / VFIO can handle > mismatched aliases w/o the machine exploding. This goes beyond > supporting Normal-NC mappings at stage-2 and is really a bug > with our current scheme (nGnRnE at stage-1, nGnRE at stage-2). > > I was hoping that (1) could be some 'common' plumbing for both userspace > and KVM mappings. And for (2), any case where a device is intolerant of > mismatches && KVM cannot force the memory attributes should be rejected. > > AFAICT, the only reason PCI devices can get the blanket treatment of > Normal-NC at stage-2 is because userspace has a Device-* mapping and can't > speculatively load from the alias. This feels a bit hacky, and maybe we > should prioritize an interface for mapping a device into a VM w/o a > valid userspace mapping. FWIW - I have tried to summarize the reasoning behind PCIe devices Normal-NC default stage-2 safety in a document that I have just realized now it has become this series cover letter, I don't think the PCI blanket treatment is related *only* to the current user space mappings (ie BTW, AFAICS it is also *possible* at present to map a prefetchable BAR through sysfs with Normal-NC memory attributes in the host at the same time a PCI device is passed-through to a guest with VFIO - and therefore we have a dev-nGnRnE stage-1 mapping for it. Don't think anyone does that - what for - but it is possible and KVM would not know about it). Again, FWIW, we were told (source Arm ARM) mismatched aliases concerning device-XXX vs Normal-NC are not problematic as long as the transactions issued for the related mappings are independent (and none of the mappings is cacheable). I appreciate this is not enough to give everyone full confidence on this solution robustness - that's why I wrote that up so that we know what we are up against and write KVM interfaces accordingly. > I very much understand that this has been going on for a while, and we > need to do *something* to get passthrough working well for devices that > like 'WC'. I just want to make sure we don't paint ourselves into a corner > that's hard to get out of in the future. That makes perfect sense, see above, if there is anything we can do to clarify we will, in whatever shape it is preferred. Thanks, Lorenzo
On Thu, Dec 14, 2023 at 04:48:15PM +0100, Lorenzo Pieralisi wrote: [...] > > AFAICT, the only reason PCI devices can get the blanket treatment of > > Normal-NC at stage-2 is because userspace has a Device-* mapping and can't > > speculatively load from the alias. This feels a bit hacky, and maybe we > > should prioritize an interface for mapping a device into a VM w/o a > > valid userspace mapping. > > FWIW - I have tried to summarize the reasoning behind PCIe devices > Normal-NC default stage-2 safety in a document that I have just realized > now it has become this series cover letter, I don't think the PCI blanket > treatment is related *only* to the current user space mappings (ie > BTW, AFAICS it is also *possible* at present to map a prefetchable BAR through > sysfs with Normal-NC memory attributes in the host at the same time a PCI > device is passed-through to a guest with VFIO - and therefore we have a > dev-nGnRnE stage-1 mapping for it. Don't think anyone does that - what for - > but it is possible and KVM would not know about it). > > Again, FWIW, we were told (source Arm ARM) mismatched aliases concerning > device-XXX vs Normal-NC are not problematic as long as the transactions > issued for the related mappings are independent (and none of the > mappings is cacheable). > > I appreciate this is not enough to give everyone full confidence on > this solution robustness - that's why I wrote that up so that we know > what we are up against and write KVM interfaces accordingly. 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 we add more behind-the-scenes tricks to get other MMIO mappings working in the future then this whole interaction will get even hairier. At least if we follow the stage-1 attributes (where possible) then we can document some sort of expected behavior in KVM. The VMM would need know if the device has read side-effects, as the only way to get a Normal-NC mapping in the guest would be to have one at stage-1. Kinda stinks to make the VMM aware of the device, but IMO it is a fundamental limitation of the way we back memslots right now.
Catching up on emails before going on holiday (again). On Thu, Dec 14, 2023 at 04:56:01PM +0000, Oliver Upton wrote: > On Thu, Dec 14, 2023 at 04:48:15PM +0100, Lorenzo Pieralisi wrote: > > > AFAICT, the only reason PCI devices can get the blanket treatment of > > > Normal-NC at stage-2 is because userspace has a Device-* mapping and can't > > > speculatively load from the alias. This feels a bit hacky, and maybe we > > > should prioritize an interface for mapping a device into a VM w/o a > > > valid userspace mapping. > > > > FWIW - I have tried to summarize the reasoning behind PCIe devices > > Normal-NC default stage-2 safety in a document that I have just realized > > now it has become this series cover letter, I don't think the PCI blanket > > treatment is related *only* to the current user space mappings (ie > > BTW, AFAICS it is also *possible* at present to map a prefetchable BAR through > > sysfs with Normal-NC memory attributes in the host at the same time a PCI > > device is passed-through to a guest with VFIO - and therefore we have a > > dev-nGnRnE stage-1 mapping for it. Don't think anyone does that - what for - > > but it is possible and KVM would not know about it). > > > > Again, FWIW, we were told (source Arm ARM) mismatched aliases concerning > > device-XXX vs Normal-NC are not problematic as long as the transactions > > issued for the related mappings are independent (and none of the > > mappings is cacheable). > > > > I appreciate this is not enough to give everyone full confidence on > > this solution robustness - that's why I wrote that up so that we know > > what we are up against and write KVM interfaces accordingly. > > 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. There are a few options here (talking in the PCIe context but it can be extended to other VFIO mappings): 1. The VMM is responsible for intra-BAR relaxation of the KVM stage 2: a) via the stage 1 VFIO mapping attributes - Device or Normal b) via other means (e.g. ioctl(<range>)) while the stage 1 VFIO stays Device 2. KVM decides the intra-BAR relaxation irrespective of the VFIO stage 1 attributes (VMM mapping) 3. KVM decides the full-BAR relaxation with the guest responsible for the intra-BAR attributes. As with (2), that's irrespective of the VFIO stage 1 host mapping Whichever option we pick, it won't be the host forcing the Normal NC mapping, that's still a guest decision and the host only allowing it. (1) needs specific device knowledge in the VMM or a VFIO-specific driver (or both if the VMM isn't fully trusted to request the right attributes). (2) moves the device-specific knowledge to KVM or a combination of KVM and VFIO-specific driver. Things can get a lot worse if the Device vs Normal ranges within a BAR are configurable and needs some paravirtualised interface for the guest to agree with the host. These patches aim for (3) but only if the host VFIO driver deems it safe (hence PCIe only for now). I find this an acceptable compromise. 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. > If we add more behind-the-scenes tricks to get other MMIO mappings > working in the future then this whole interaction will get even > hairier. At least if we follow the stage-1 attributes (where possible) > then we can document some sort of expected behavior in KVM. The VMM would > need know if the device has read side-effects, as the only way to get a > Normal-NC mapping in the guest would be to have one at stage-1. I don't think KVM or the VMM should attempt to hand-hold the guest and ensure that it maps an MMIO with read side-effects appropriately. The guest driver can do this by itself or get incorrect hw behaviour. Such hand-holding is only needed if the speculative loads have wider system implications but we concluded that it's not the case for PCIe. Even with a Device mapping, the guest can always issue random reads from an assigned MMIO range and cause side-effects. > Kinda stinks to make the VMM aware of the device, but IMO it is a > fundamental limitation of the way we back memslots right now. As I mentioned above, the limitation may be more complex if the intra-BAR attributes are not something readily available in the device documentation. Maybe Jason or Ankit can shed some light here: are those intra-BAR ranges configurable by the (guest) driver or they are already pre-configured by firmware and the driver only needs to probe them? Anyway, about to go on the Christmas break, so most likely I'll follow up in January. Happy holidays!
On Thu, Dec 21, 2023 at 01:19:18PM +0000, Catalin Marinas wrote: > 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. If we use a FD then KVM will be invoking some API on the FD to get the physical memory addreses and we can have that API also return information on the allowed memory types. > > Kinda stinks to make the VMM aware of the device, but IMO it is a > > fundamental limitation of the way we back memslots right now. > > As I mentioned above, the limitation may be more complex if the > intra-BAR attributes are not something readily available in the device > documentation. Maybe Jason or Ankit can shed some light here: are those > intra-BAR ranges configurable by the (guest) driver or they are already > pre-configured by firmware and the driver only needs to probe them? Configured by the guest on the fly, on a page by page basis. There is no way for the VMM to pre-predict what memory type the VM will need. The VM must be in control of this. Jason
On Wed, Dec 13, 2023 at 08:05:29PM +0000, Oliver Upton wrote: > Hi, > > Sorry, a bit late to the discussion :) > > On Tue, Dec 12, 2023 at 02:11:56PM -0400, Jason Gunthorpe wrote: > > On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote: > > > 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. > > > > DPDK won't rely on this interface > > Wait, so what's the expected interface for determining the memory > attributes at stage-1? I'm somewhat concerned that we're conflating two > things here: Someday we will have a VFIO ioctl interface to request individual pages within a BAR be mmap'd with pgprot_writecombine(). Only something like DPDK would call this ioctl, it would not be used by a VMM. > 1) KVM needs to know the memory attributes to use at stage-2, which > isn't fundamentally different from what's needed for userspace > stage-1 mappings. > > 2) KVM additionally needs a hint that the device / VFIO can handle > mismatched aliases w/o the machine exploding. This goes beyond > supporting Normal-NC mappings at stage-2 and is really a bug > with our current scheme (nGnRnE at stage-1, nGnRE at stage-2). Not at all. This whole issue comes from a fear that some HW will experience an uncontained failure if NORMAL_NC is used for access to MMIO memory. Marc pointed at some of the GIC registers as a possible concrete example of this (though nobody has come with a concrete example in the VFIO space). When KVM sets the S2 memory types it is primarily making a decision what memory types the VM is *NOT* permitted to use, which is fundamentally based on what kind of physical device is behind that memory and if the VMM is able to manage the cache. Ie the purpose of the S2 memory types is to restrict allowed VM memory types to protect the integrity of the machine and hypervisor from the VM. Thus we have what this series does. In most cases KVM will continue to do as it does today and restrict MMIO memory to Device_XX. We have a new kind of VMA flag that says this physical memory can be safe with Device_* and Normal_NC, which causes KVM to stop blocking VM use of those memory types. > I was hoping that (1) could be some 'common' plumbing for both userspace > and KVM mappings. And for (2), any case where a device is intolerant of > mismatches && KVM cannot force the memory attributes should be rejected. It has nothing to do with mismatches. Catalin explained this in his other email. > AFAICT, the only reason PCI devices can get the blanket treatment of > Normal-NC at stage-2 is because userspace has a Device-* mapping and can't > speculatively load from the alias. This feels a bit hacky, and maybe we > should prioritize an interface for mapping a device into a VM w/o a > valid userspace mapping. Userspace has a device-* mapping, yes, that is because userspace can't know anything better. > I very much understand that this has been going on for a while, and we > need to do *something* to get passthrough working well for devices that > like 'WC'. I just want to make sure we don't paint ourselves into a corner > that's hard to get out of in the future. Fundamentally KVM needs to understand the restrictions of the underlying physical MMIO, and this has to be a secure indication from the kernel component supplying the memory to KVM consuming it. Here we are using a VMA flag, but any other behind-the-scenes scheme would work in the future. Jason
On Tue, Jan 02, 2024 at 01:09:08PM -0400, Jason Gunthorpe wrote: > On Thu, Dec 21, 2023 at 01:19:18PM +0000, Catalin Marinas wrote: > > 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. > > If we use a FD then KVM will be invoking some API on the FD to get the > physical memory addreses and we can have that API also return > information on the allowed memory types. I think the part with a VFIO WC flag wouldn't be any different. The fd-based mapping only solves the mismatched alias, otherwise the decision for Normal NC vs Device still lies with the guest driver. > > > Kinda stinks to make the VMM aware of the device, but IMO it is a > > > fundamental limitation of the way we back memslots right now. > > > > As I mentioned above, the limitation may be more complex if the > > intra-BAR attributes are not something readily available in the device > > documentation. Maybe Jason or Ankit can shed some light here: are those > > intra-BAR ranges configurable by the (guest) driver or they are already > > pre-configured by firmware and the driver only needs to probe them? > > Configured by the guest on the fly, on a page by page basis. > > There is no way for the VMM to pre-predict what memory type the VM > will need. The VM must be in control of this. That's a key argument why the VMM cannot do this, unless we come up with some para-virtualised interface and split the device configuration logic between the VMM and the VM. I don't think that's feasible, too much complexity.
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 :)
On Fri, Jan 05, 2024 at 08:42:31PM +0000, Oliver Upton wrote: > 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 by policy you mean who's deciding the write-combining relaxation, this series moved it to the vfio-pci host driver. KVM only picks the appropriate memory type for stage 2 based on the vma flags. That's Normal NC in the absence of anything better on arm64 and it does more than just write-combining but we can describe what this new VM_* flag allows. If we want to keep this decision strictly in user space, we can do it with some ioctl(). The downside is that the host kernel now puts more trust in the user VMM, so my preference would be to keep this in the vfio driver. Or we can do both, vfio-pci allows the relaxation, the VMM tells KVM to go for a more relaxed stage 2 via an ioctl().
On Mon, Jan 08, 2024 at 11:04:47AM +0000, Catalin Marinas wrote: > If we want to keep this decision strictly in user space, we can do it > with some ioctl(). The downside is that the host kernel now puts more > trust in the user VMM, so my preference would be to keep this in the > vfio driver. Or we can do both, vfio-pci allows the relaxation, the VMM > tells KVM to go for a more relaxed stage 2 via an ioctl(). What is the point? We'd need a use case for why the VMM should have the ability to create a more restrictive MMIO mapping. I can't think of one. So I'd go the other way, if someday we find out we need more restrictive then the VMM should ask for more restrictive (not weirdly ask for less restrictive) Jason
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; + if (device) attr = KVM_S2_MEMATTR(pgt, DEVICE_nGnRE); else if (normal_nc) 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; 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); + /* Don't use the VMA after the unlock -- it may have vanished */ vma = NULL; @@ -1557,8 +1559,16 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, if (exec_fault) prot |= KVM_PGTABLE_PROT_X; - if (device) - prot |= KVM_PGTABLE_PROT_DEVICE; + if (device) { + /* + * To provide VM with the ability to get device IO memory + * with NormalNC property, map device MMIO as NormalNC in S2. + */ + if (vfio_pci_device) + prot |= KVM_PGTABLE_PROT_NORMAL_NC; + else + prot |= KVM_PGTABLE_PROT_DEVICE; + } else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) prot |= KVM_PGTABLE_PROT_X; 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); 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 */ +#define VM_VFIO_ALLOW_WC BIT(VM_VFIO_ALLOW_WC_BIT) +#else +#define VM_VFIO_ALLOW_WC VM_NONE +#endif + /* Bits set in the VMA until the stack is in its final location */ #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)