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 33D76C64ED9 for ; Mon, 20 Feb 2023 16:41:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C249D6B0074; Mon, 20 Feb 2023 11:41:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BD4746B0075; Mon, 20 Feb 2023 11:41:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A75646B0078; Mon, 20 Feb 2023 11:41:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 987C06B0074 for ; Mon, 20 Feb 2023 11:41:43 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6AD86A0A70 for ; Mon, 20 Feb 2023 16:41:43 +0000 (UTC) X-FDA: 80488236486.10.012B8A4 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2057.outbound.protection.outlook.com [40.107.244.57]) by imf25.hostedemail.com (Postfix) with ESMTP id 82971A000E for ; Mon, 20 Feb 2023 16:41:40 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=b+hRllSZ; spf=pass (imf25.hostedemail.com: domain of Michael.Roth@amd.com designates 40.107.244.57 as permitted sender) smtp.mailfrom=Michael.Roth@amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=quarantine) header.from=amd.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676911300; 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=MYG2F/Kz+L66kuyTglO+w54eANn764HnkaGxzcD/lIo=; b=CE9Q542alA2i3N2zBNv5OWaENp1657yWRa4JnoussjwnQI+4VNyeTyodix4H37JOakgaSK eQd8Gf1R3m1XUwLpxQd3X7jqDR1NNhJaV1g4TFygCDiW3UTTJuypNdGXiDefWVr38fMD4K Nk11ZauSNIFn3ydL8EF3yp/iOo6f2kQ= ARC-Authentication-Results: i=2; imf25.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=b+hRllSZ; spf=pass (imf25.hostedemail.com: domain of Michael.Roth@amd.com designates 40.107.244.57 as permitted sender) smtp.mailfrom=Michael.Roth@amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=quarantine) header.from=amd.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1676911300; a=rsa-sha256; cv=pass; b=wy8qYdXAx+aoHxDPAxJt1yPwf0ejvsk1LJZyAChG9XJfSXQ0wGNXZtOnZckCMCd1kl8UMT JZhUB37mQdnLEx1JykI4LlioY+aDGEozIxOB18pHCRssDY3rknXTdo9iQUntSXOqSMvdNU ngtxvQJiaXIy6QNEViXWbTp2soreDwQ= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O5L7DJf4LmtelcC9wBjZcNgb6+ELX7sAhrS3RViOZPq7ukAQkZHDHLuhnso/3TetGMUP0tzuyGdNjxUXhEKZt5KGyKSc1OW179SkGTQC1E2m36Ifs2TFx8hct5QD8HOBpZmUCcr0u+W5C2nTgeaz6Djq01KGTE7SnWGGeaBH1dvUe7jfpyi+3f6/cMLcAHi3MoI90C/GTR3nWK4klRGWDbt0+sUfulyxamJVEMzqCm+DVQeENv0BLAUYUAhgq1yFYmGIe7B+dluN7ybZNEvCbWrKGORbMcqEmH+ka5Lk9Lx7p4cwtLleUQ7iHCa873oa09VyOwUKvzhGTi73BaLckQ== 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=MYG2F/Kz+L66kuyTglO+w54eANn764HnkaGxzcD/lIo=; b=ja+wRfDFx66hQVuYY4e0ZVuKvF9bXwOHuCJGXkcrs4OG5CweokyzdeeBjvTKaYM6EIEFhb7EncSkB/evZs0Hm1HcuNjRKb+TNgn0AVY+iLEc5/oiJMuho0hvkBd8QpLeZuz4fzOUTQJuIJOGTGX04Sk5QjZj+EcOiexmLJPTKjf5Dd1wyEpAkep4BMjFT0HYhSqlwKGpn4zAqaBYbvDR4qWaUSCKvU+tKoo0oDHlI3OmvyxoIc05PRvQdSaEYjhE7vJ3FZkkqsQGTlLjGdWWaM/59+lD+sh4n86b9x+sKydefJKLNwJBtTy4Pqvqit6mmowuttZwxrnak49ncsfnvA== 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 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=MYG2F/Kz+L66kuyTglO+w54eANn764HnkaGxzcD/lIo=; b=b+hRllSZL33xnPNb455ex0qZG3NS8LcxVtfkdSzJu8WEVabrhLx4tm1ZSWrsKmHcYB6ltIrv8KdA4zdOzFiedtVH4jNTuZIyNh1mL/Qct/aSrGdjEUt+SkqzZc0zMk0Zuyg/Bph/+VMbv3ll6EEwi+mnLMAdbOWszLzPKTwBDpQ= Received: from BN9PR03CA0085.namprd03.prod.outlook.com (2603:10b6:408:fc::30) by IA1PR12MB6233.namprd12.prod.outlook.com (2603:10b6:208:3e7::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.19; Mon, 20 Feb 2023 16:41:36 +0000 Received: from BN8NAM11FT082.eop-nam11.prod.protection.outlook.com (2603:10b6:408:fc:cafe::3e) by BN9PR03CA0085.outlook.office365.com (2603:10b6:408:fc::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.19 via Frontend Transport; Mon, 20 Feb 2023 16:41:36 +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 BN8NAM11FT082.mail.protection.outlook.com (10.13.176.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6111.20 via Frontend Transport; Mon, 20 Feb 2023 16:41:36 +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.2375.34; Mon, 20 Feb 2023 10:41:35 -0600 Date: Mon, 20 Feb 2023 10:22:10 -0600 From: Michael Roth To: Sean Christopherson CC: Borislav Petkov , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH RFC v7 04/64] KVM: x86: Add 'fault_is_private' x86 op Message-ID: <20230220162210.42rjdgbdwbjiextz@amd.com> References: <20221214194056.161492-1-michael.roth@amd.com> <20221214194056.161492-5-michael.roth@amd.com> <20230105024256.ptujtjgzcdmpakoa@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: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8NAM11FT082:EE_|IA1PR12MB6233:EE_ X-MS-Office365-Filtering-Correlation-Id: b6c2e143-74b1-423a-2241-08db1361556b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cP6+xIqw9Siwm1AsQbGq3lUcyP+SuryfSqfArKD40Dzj2bvBy2ZCoKtQKi+zao/5bZErIalPmMMpkPRKVO3QnbFAQI6pXPmnVHRtnnJEIiuUeUW/QFTifxvF5s7Xt9VULWiDxJwSL+UwIVG7cu2GrKvFGPttm3Cqhzl6R5NOFBw7Z8CVPhMdt+IdSRBrhoEXizRYsXBP8m9XXDMfJwa3glbqBF/4veEwFv5YAmi0f+nT7cp5Ls5xsrFStI7WpqLpCtz+GrBGCA+rXjwlVSsdf2S4QidMIA/xgza4Hhzbi+883+tK5lwhE/JF5sVbCRiPrEnxv0QAY9Np0cE3Hp37XNU8EuSCU2Bg3WgPZ2rDyi2Ss8IV8dQWvVpkww/grOlHIorV4b7r4EcU2wxVZuK9tsNIvNE4t2RQPVnrniZG8H2HbwiReDt4FnkijeVBa/YHZey4edIiE4oiYRECf+zhxcnB9Uosi+/+REpy3ERkR5ycAL6KKIbK9MOtUl/yRnaV+IqMEBKyR3FNoCdwUFYGBYRX3N5fUa/K12cechZBA+DtwWUQb1gBKvpAjJsWvFTGAxSUJfeYcq5n9xs9n1xoqnA4JNPww9u2LvRH9DgnhHJKTCSQ+GWBRym5Bhvy5AF/x/PzVA44J2iIXkQQ9MupVFIAvuEIsNIsUTz+4Tj+F2Nr7iyEqz1jANyQhoYwKq4iiM3F/utOaFOOiZCEod4ujQOXekpczbxcHn3erXcXibA= 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:(13230025)(4636009)(376002)(346002)(136003)(396003)(39860400002)(451199018)(46966006)(40470700004)(36840700001)(66899018)(8676002)(70206006)(70586007)(6916009)(4326008)(316002)(7406005)(54906003)(7416002)(44832011)(8936002)(5660300002)(41300700001)(40460700003)(36756003)(86362001)(356005)(478600001)(16526019)(6666004)(26005)(186003)(1076003)(2616005)(336012)(47076005)(426003)(2906002)(82310400005)(40480700001)(81166007)(36860700001)(82740400003)(83380400001)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2023 16:41:36.7959 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b6c2e143-74b1-423a-2241-08db1361556b 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: BN8NAM11FT082.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6233 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 82971A000E X-Stat-Signature: 8i3kuosznzobtm348x4u4gqxqkd4s9uq X-HE-Tag: 1676911300-696826 X-HE-Meta: U2FsdGVkX1/PfKMXvqmkAY6x4hVnP0RKcSc0osILeFRRaIqpX+Ybs5lWoa5HLXfUieRF930X5rnFxNhPiFQ4J9FZNfh2jtGNnAPKFBP0rSD7kAdLiGNzFf8jxLx9agfFGfw9spR0kklnmKp2U9u9Z0FHYub6hT3vZGL4FlBh5nGwEqg439P2999ZDLuqGkoTMtlI0Mw59pW6N+amJ7wZjfUeRQVXIzHul+YJ5U98a/REint/BjdZSfu3UzPSw4juCxPTYgUaQ90uHk3fsCkwfdxZhUYi0X2RbRRqRM9U/EjMMlSLixi8Fi1hMSjTekl1ApqCbmw3aaRO3z06U5f9XvVJC/oEWQLFSRfwt1PY+1nK7hc8z8N9AC158BQsEjemmFJhM6V5OrNSl640l69S8EBl/ruGY6WIzycsmbNKiUwVMgcihycXB/IQW8csVX5uYNQN8A+XVh14F7KcEeqsh0agoCeGiuRE98xo0iLgcEPw8BopmqoO0PVp7QWhLgviLwPycn+OJ58ihiXuZEfDuqbUsxAbBUGHaxA0Tn+e/d2PY2GAf3X/803yBEVwkr+M04IyXsaG9pjA6SQT/gWwoVUptEa5mSYVAWmind7hJsEieWfO03z3y+D/pbq+QjqIQU0h0FEmKt9yyc3+6acF6dN8mfYmGxwfIx7js0qitfzI1td5YNbG0Z8cnPGR+pIoEEcRsy37trdaUVk+gmPgPYXi35pPKngWkY32mNjvO6jIfgLvwUTeB1jpMXYWSs6CXEuDmypoEVvUrmRPDjZKmSLLcQSBV3x0nmD7lYl3yFsf5DGU/89LLTA2kCma4cCrc0jQ/0wfJ0//Hjgb3/xMEXQXYQrbH++VVVhSUF8r1XLLOhG73CGT+/GUsGM/7bxY/Dyh34Z2C672sGC3TXB6bnr13D0MEp1zsISejGQSHn3OW7HehURQnAUeOZrtj4THZqdZtgNqFarXtZnXR/Y EMwdr+H0 qoTqB7CaZ6VsEog9/tCSsjCHNPTgGNmRcxE8bKMIIp9C7hv1K8r3+OCWsFJn+cSkrJzzkWD1lHi7yNOOhTTYQ+yxTBoEe0AtRrjF06Zog6OZXb9lCKRF/UoaUKQ/L9iIm9f2oMfI8P2ZkhvGa8+j/JMKPBcZS3lH8rmsCssbKed9QD6jfvGuwbTdKQyyLk3uN8X2d/vcRVE8xnJfxyDXXpHhZdI0yArKODb7g+jJ8CTctCx26WiX158Sxry3SEzI8pUti52wnGiPD51MdtXBoAOgVFpcgyhpR4u1BeuGqzVjXGQ27eq6KEVO7SSJ5Lxpw/EnxbA5P90KJf6pd+kyYmCnSLbY7QvOugkjvORa2gQAvigA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000465, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jan 13, 2023 at 03:48:59PM +0000, Sean Christopherson wrote: > On Fri, Jan 13, 2023, Borislav Petkov wrote: > > On Wed, Jan 04, 2023 at 08:42:56PM -0600, Michael Roth wrote: > > > Obviously I need to add some proper documentation for this, but a 1 > > > return basically means 'private_fault' pass-by-ref arg has been set > > > with the appropriate value, whereas 0 means "there's no platform-specific > > > handling for this, so if you have some generic way to determine this > > > then use that instead". > > > > Still binary, tho, and can be bool, right? > > > > I.e., you can just as well do: > > > > if (static_call(kvm_x86_fault_is_private)(kvm, gpa, err, &private_fault)) > > goto out; > > > > at the call site. > > Ya. Don't spend too much time trying to make this look super pretty though, there > are subtle bugs inherited from the base UPM series that need to be sorted out and > will impact this code. E.g. invoking kvm_mem_is_private() outside of the protection > of mmu_invalidate_seq means changes to the attributes may not be reflected in the > page tables. > > I'm also hoping we can avoid a callback entirely, though that may prove to be > more pain than gain. I'm poking at the UPM and testing series right now, will > circle back to this and TDX in a few weeks to see if there's a sane way to communicate > shared vs. private without having to resort to a callback, and without having > races between page faults, KVM_SET_MEMORY_ATTRIBUTES, and KVM_SET_USER_MEMORY_REGION2. Can circle back on this, but for v8 at least I've kept the callback, but simplified SVM implementation of it so that it's only needed for SNP. For protected-SEV it will fall through to the same generic handling used by UPM self-tests. It seems like it's safe to have a callback of that sort here for TDX/SNP (or whatever we end up replacing the callback with), since the #NPF flags themselves won't change based on attribute updates, and the subsequent comparison to kvm_mem_is_private() will happen after mmu_invalidate_seq is logged. But for protected-SEV and UPM selftests the initial kvm_mem_is_private() can become stale vs. the one in __kvm_faultin_pfn(), but it seems like ATM it would only lead to a spurious KVM_EXIT_MEMORY_FAULT, which SEV at least should treat at an implicit page-state change and be able to recover from. But yah, not ideal, and maybe for self-tests that makes it difficult to tell if things are working as expected or not. Maybe we should just skip setting fault->is_private here in the non-TDX/non-SNP cases, and just have some other indicator so it's initialized/ignored in kvm_mem_is_private() later. I think some iterations of UPM did it this way prior to 'is_private' becoming const. > > > > This is mainly to handle CONFIG_HAVE_KVM_PRIVATE_MEM_TESTING, which > > > just parrots whatever kvm_mem_is_private() returns to support running > > > KVM selftests without needed hardware/platform support. If we don't > > > take care to skip this check where the above fault_is_private() hook > > > returns 1, then it ends up breaking SNP in cases where the kernel has > > > been compiled with CONFIG_HAVE_KVM_PRIVATE_MEM_TESTING, since SNP > > > relies on the page fault flags to make this determination, not > > > kvm_mem_is_private(), which normally only tracks the memory attributes > > > set by userspace via KVM_SET_MEMORY_ATTRIBUTES ioctl. > > > > Some of that explanation belongs into the commit message, which is a bit > > lacking... > > I'll circle back to this too when I give this series (and TDX) a proper look, > there's got too be a better way to handle this. > It seems like for SNP/TDX we just need to register the shared/encrypted bits with KVM MMU and let it handle checking the #NPF flags, but can iterate on that for the next spin when we have a better idea what it should look like. -Mike