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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3238C4828F for ; Thu, 8 Feb 2024 00:24:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E71A6B0075; Wed, 7 Feb 2024 19:24:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0975D6B0078; Wed, 7 Feb 2024 19:24:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E53386B007D; Wed, 7 Feb 2024 19:24:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D1F816B0075 for ; Wed, 7 Feb 2024 19:24:45 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9649F120983 for ; Thu, 8 Feb 2024 00:24:45 +0000 (UTC) X-FDA: 81766740930.25.8F324D6 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2041.outbound.protection.outlook.com [40.107.92.41]) by imf03.hostedemail.com (Postfix) with ESMTP id 8526220016 for ; Thu, 8 Feb 2024 00:24:42 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=1YtD7J8G; spf=pass (imf03.hostedemail.com: domain of Michael.Roth@amd.com designates 40.107.92.41 as permitted sender) smtp.mailfrom=Michael.Roth@amd.com; dmarc=pass (policy=quarantine) header.from=amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707351882; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/CYBAY5yRIT9SKIkZFN8jpfkACBa/PVJwqDruYaCGOY=; b=QvRAh8QravDBCPJu14+vMjWfrwLIbDm8KyKNSKQlPd6uZ/uWJZ4Hi45qdtCOCF80xIGZKs nyvZ41FbqZzkf6UfL8vNvGA8qIZpMuZvMP/tN25EtABTgQ5oRQFj6Yyd7Zp742O+TSz81c hp2IdeSnLFp/4II3FA1eZKlRXKmlk+E= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1707351882; a=rsa-sha256; cv=pass; b=Wqj9U/pgB/CIa7SERWjQVf/UlgHijt9t41nAiHZZQsOZqgjkMT0BnQPG6t3n4WTn3zGrlX oRqSarJNWUUvHR0M0FX776/Pl4H4htgg7a69kNYjsAzXhTP/S7/aJINDVbmBy7D8Gutdi4 ucoCB25FK/73UaldEq10i3TSi9BKDsI= ARC-Authentication-Results: i=2; imf03.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=1YtD7J8G; spf=pass (imf03.hostedemail.com: domain of Michael.Roth@amd.com designates 40.107.92.41 as permitted sender) smtp.mailfrom=Michael.Roth@amd.com; dmarc=pass (policy=quarantine) header.from=amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=da5i96kltwco148uw98uOhprLh+nfRKUtr2VA4j8UXFevJh++aI8PQ+Q1QTKFT3zEhCdRc6olllSgWmazDt9kE0oCCe+rlnwNLYDUPnpU/tTNwmUEhKFuyFVE0M7SgjbGQewyHchFJBvhhoy05ht/GJK5hf3Vqf/LVqcihLwcgAbH/kVsLgkpjXrjVuslBjmzg+g3wqQkrJfVElMHpfOKmeBCOmpdjHr0KMzm9G3H2sjeOVNlB6JJ5FVtaRnRD+M5DQFIBoLlw9F+QCEU2gQYpvkrDvfFh3o+ZMcuyYwfCDqW6Q8Lgx06HKWvtPTOndXCprEyb35XgENC3l5WvcQDQ== 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=/CYBAY5yRIT9SKIkZFN8jpfkACBa/PVJwqDruYaCGOY=; b=kgZ2mrtIxxy/R3Q2hIGD5VWDpRjovlpGdKivFi/w/QbzVCAGp0Kq8gFYY+AOEZG8vCM8pJUPB46T76S+brZiZdegDuQZo75MQlJnsOFIHATiC3BqyqR6I8gs5EhHt3WXFgMlId7zKjLlh7Vqmk1nUnStPk5Q8m7NwRLtJd+zTyq5Kz3vQS1ar+KxjzCnta95hZG9N6TpO3cHNhhh2xCmGYT/B+9hltmoRfNwbj4qhgoqAALJmZTgvxkVAL9D+UUxp+OerbEcucm9JK9yBywKzBMPzCn3gCR6gMWrf3WJJSYdB4YUiTGk6e4ObZ9ipoNJrUr+wBTy/oWraIrxMdSyXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=google.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/CYBAY5yRIT9SKIkZFN8jpfkACBa/PVJwqDruYaCGOY=; b=1YtD7J8G6dEfDHKnjz5QjepfHP+uf/ZY0aiu0s+Jr+ouHzFcmNcT51v4atN/pVsuhzP8PkQ4ehdiQBMJLiNVZrqsLTvT42Fb5939IOaqmPcT/J3/yABuJLhHfMVCmEr9PbmajLorliPSpYRDZHi0mzrZlrTYrdmhlrZPOtnleRo= Received: from BYAPR07CA0086.namprd07.prod.outlook.com (2603:10b6:a03:12b::27) by PH8PR12MB8431.namprd12.prod.outlook.com (2603:10b6:510:25a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.14; Thu, 8 Feb 2024 00:24:39 +0000 Received: from CO1PEPF000044F1.namprd05.prod.outlook.com (2603:10b6:a03:12b:cafe::ba) by BYAPR07CA0086.outlook.office365.com (2603:10b6:a03:12b::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.38 via Frontend Transport; Thu, 8 Feb 2024 00:24:39 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1PEPF000044F1.mail.protection.outlook.com (10.167.241.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7249.19 via Frontend Transport; Thu, 8 Feb 2024 00:24:39 +0000 Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Wed, 7 Feb 2024 18:24:38 -0600 Date: Wed, 7 Feb 2024 18:24:20 -0600 From: Michael Roth To: Sean Christopherson CC: , , , , , , , , , , , , , , , Subject: Re: [PATCH RFC gmem v1 8/8] KVM: x86: Determine shared/private faults based on vm_type Message-ID: <20240208002420.34mvemnzrwwsaesw@amd.com> References: <20231016115028.996656-1-michael.roth@amd.com> <20231016115028.996656-9-michael.roth@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF000044F1:EE_|PH8PR12MB8431:EE_ X-MS-Office365-Filtering-Correlation-Id: 68cf77cf-ad8e-40af-c1dc-08dc283c5688 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BpLq/KEt89wK2BWexDAJoBmv1kYonYPuq8V6uE/+q2xPJRy8ohVWjQNNs1y+I1OgOqHnMYe0j58f/uPWMB83HFaSJTbJZv5ZwXLa+IyKLRowhxjvFwViD4vTToetTOf+AwsIphJYbL55ex+iRZbibrPOy4k97Y4a9R8WQDD6ZCfGnfKc+Wz0ZJLoyu0VYD4nLw9gdEyon9Yq4UYMZkPO3s0Ubf0sM5MLpJitHmYmRPmwcyQHiIA4TGvi8gTodAKtAMx0ACnSZPUB2C68vjoThdK8NVWJLUx7k9q7NBEiELqBSIRsbnrf4OFpt4Yq3lFXqQUwTtyc4cMn8fOcGt/QQ8LkXcpIH9u62R03QsqrPeQwW+gccXn0X0HhR/wdMJ2qJXsBtJ+Z22DX3q5tMx7hcRNXP9Bc2KHXP1Oe71RTl9q2d4CRPRV1frifqFJRCgntf3It325MMMHLtojAPH5f4Lz4GqblyGdEquzY8AkNw5MUUmbovGaFg5SJz4H5GKWlMaE7rSreAft5soLUCwcVBKCH/bHh1Cuo9/zznQJzam7gks6lehOMEnunJZcgU4Av02tH+fgCkpWRLBa56Lk2+Q== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(376002)(396003)(39860400002)(136003)(346002)(230922051799003)(186009)(451199024)(64100799003)(1800799012)(82310400011)(40470700004)(46966006)(36840700001)(478600001)(86362001)(41300700001)(966005)(83380400001)(82740400003)(356005)(81166007)(336012)(426003)(8936002)(66899024)(6666004)(316002)(4326008)(6916009)(2906002)(5660300002)(36756003)(16526019)(26005)(70206006)(54906003)(7416002)(8676002)(44832011)(70586007)(2616005)(1076003);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2024 00:24:39.3001 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 68cf77cf-ad8e-40af-c1dc-08dc283c5688 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000044F1.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB8431 X-Rspamd-Queue-Id: 8526220016 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 75hbre74ftp8woch65fksz83d7x7bt7n X-HE-Tag: 1707351882-701960 X-HE-Meta: U2FsdGVkX19/St5vkCFkRj14Gemuas3sY79JHT24HsyyP94rsL/8KXCp4IbhjaZ0wXNBDY/LjwisQdR2dUmrt/fxxodj4l54fGGl7RFDtsp5T6Fiu3qvdzVLoWyEjxpGVhKLNhIHEGspJtspDRJVHKro8Q054qOaHK/D+P9wrgoATKqviucSLYBv1pygtfcIFxgX8NRY80jiR+4qDF8Ars4M1ruv+fUxM+SarUayxEvN5+XoV4EuyJQ3YrvkLvgRMJPoySrIg44L09hGEGql4OuBYM8vgNZMsC3mWpmOm6SqHcHf7ZVmZeqOR7uCms4dyjqDPPYBx29BT20/q1nhFKUh144IxFrmsV7331Om9WtNmx4VoDZwT6okN4Ocg3IAbCaYV2XZLkCytnzi81tUsbp48jWrF1BVpaWkpcKON1dRXpbw/zp2/w0fOgTzjeKSdRDjhwjpyn287VkfBi9CFfToJN2imVwp4xMJxCJt5qaURypnU8t6UnVOiQd+H6AXTcwvv0xUymz+Vi8dBwPKUBXTBHj/S1tDW2NCrd9QXKr+Rm+qFgVuYVUnx9piHBxS3TMiwNre3LDTBUuzqsV5Lqclyt5cFe3Qc8hZRH+KnUhzgTIta2zroHSaXqbmXGgUVgpuahWj4KhdpFYVagr8kQFnbuVKxalllx8F9zlF9SDCM6oFsunUZ5gBaHGoEhDnIYvO7XiSdrHneLzv5hSdewlC44fFnPtZkYT3ZX4/+RtATEg70+7Dg7NDYMZaG0PmQlnPHumoro57N6+SLfLJEY4NgyS0iiR+133X528yq60gAW/XaDcvw/tUgHxDv7UDk45SWeLPZUFiLwhc4YlEyGRGZoOJZDndl0w2i6bhmqXIZqHvLXvBwJKuqL4N+1jGxLhqHLzn5r8LLFHdqnNLqApPaKia6Ncq5Y9Q8yiul/r0fUTDUYnwIjpJFQ5F3j04nQ+UBhfbH9uhse6I6sv qRuJJz6v Q9uG4r8VtqQtW3hVszVF6HUHNrrRRdbJXnHcLtToLuQ/nOntdGN1StVGU7JoaJcm8JxFq7JAuFG8thlYuP+YkbwSLsqsID6k24xCeZisBySqBY869RnSj46Euz01/fIfzqMU8gfS6Ps2WBb80ngYEYC0/3OpMRJhtyfplGXbnOJsKhkXH5O6ouJ2S64M6/YApi3O1pXKI5SgHfRSGzZjgW5w+sozFPrjGf200xPuANaYVvl/JvGSxzj8VRrkcpd9WrtK3R/kdhk9JYwyxPoEI/f1C7M+tX8MVjcSvlSK+AZ/q6Tt/4YcR0mbePubPfUfXzGD/KyIEyqC72gxbLPInUfET9n/kjJ2IVcuLWac5fYzHiGhmLiaea7dwp1zjZaw1TzwFfpLMieFJfz15SKMHOiDei5U9DqgBIXcyOsBvJSOaqcEzmRBbbM4ttIgLiZtxNRJzvW7S/C91rbj+MSE8/vv3ImzJnmhxCqeqEDozng2dEocdk+eCdTVBQiRue+O5GKYve8MI1B2Bm6xVDx1b7R3GTUTwNqpHqJ9ZQ5Z22OlWO90= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jan 30, 2024 at 05:13:00PM -0800, Sean Christopherson wrote: > On Mon, Oct 16, 2023, Michael Roth wrote: > > For KVM_X86_SNP_VM, only the PFERR_GUEST_ENC_MASK flag is needed to > > determine with an #NPF is due to a private/shared access by the guest. > > Implement that handling here. Also add handling needed to deal with > > SNP guests which in some cases will make MMIO accesses with the > > encryption bit. > > ... > > > @@ -4356,12 +4357,19 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > > return RET_PF_EMULATE; > > } > > > > - if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { > > + /* > > + * In some cases SNP guests will make MMIO accesses with the encryption > > + * bit set. Handle these via the normal MMIO fault path. > > + */ > > + if (!slot && private_fault && kvm_is_vm_type(vcpu->kvm, KVM_X86_SNP_VM)) > > + private_fault = false; > > Why? This is inarguably a guest bug. AFAICT this isn't explicitly disallowed by the SNP spec. There was however a set of security mitigations for SEV-ES that resulted in this being behavior being highly discouraged in linux guest code: https://lkml.org/lkml/2020/10/20/464 as well as OVMF guest code: https://edk2.groups.io/g/devel/message/69948 However the OVMF guest code still allows 1 exception for accesses to the local APIC base address, which is the only case I'm aware of that triggers this condition: https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c#L100 I think the rationale there is that if the guest absolutely *knows* that encrypted information is not stored at a particular MMIO address, then it can selectively choose to allow for exceptional cases like these. So KVM would need to allow for these cases in order to be fully compatible with existing SNP guests that do this. > > > + if (private_fault != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { > > kvm_mmu_prepare_memory_fault_exit(vcpu, fault); > > return -EFAULT; > > } > > > > - if (fault->is_private) > > + if (private_fault) > > return kvm_faultin_pfn_private(vcpu, fault); > > > > async = false; > > diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h > > index 759c8b718201..e5b973051ad9 100644 > > --- a/arch/x86/kvm/mmu/mmu_internal.h > > +++ b/arch/x86/kvm/mmu/mmu_internal.h > > @@ -251,6 +251,24 @@ struct kvm_page_fault { > > > > int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault); > > > > +static bool kvm_mmu_fault_is_private(struct kvm *kvm, gpa_t gpa, u64 err) > > +{ > > + bool private_fault = false; > > + > > + if (kvm_is_vm_type(kvm, KVM_X86_SNP_VM)) { > > + private_fault = !!(err & PFERR_GUEST_ENC_MASK); > > + } else if (kvm_is_vm_type(kvm, KVM_X86_SW_PROTECTED_VM)) { > > + /* > > + * This handling is for gmem self-tests and guests that treat > > + * userspace as the authority on whether a fault should be > > + * private or not. > > + */ > > + private_fault = kvm_mem_is_private(kvm, gpa >> PAGE_SHIFT); > > + } > > This can be more simply: > > if (kvm_is_vm_type(kvm, KVM_X86_SNP_VM)) > return !!(err & PFERR_GUEST_ENC_MASK); > > if (kvm_is_vm_type(kvm, KVM_X86_SW_PROTECTED_VM)) > return kvm_mem_is_private(kvm, gpa >> PAGE_SHIFT); > Yes, indeed. But TDX has taken a different approach for SW_PROTECTED_VM case where they do this check in kvm_mmu_page_fault() and then synthesize the PFERR_GUEST_ENC_MASK into error_code before calling kvm_mmu_do_page_fault(). It's not in the v18 patchset AFAICT, but it's in the tdx-upstream git branch that corresponds to it: https://github.com/intel/tdx/commit/3717a903ef453aa7b62e7eb65f230566b7f158d4 Would you prefer that SNP adopt the same approach? -Mike