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 16AC2C4345F for ; Thu, 25 Apr 2024 22:00:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A3826B0098; Thu, 25 Apr 2024 18:00:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 82C436B009A; Thu, 25 Apr 2024 18:00:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 658AB6B009B; Thu, 25 Apr 2024 18:00:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4248D6B0098 for ; Thu, 25 Apr 2024 18:00:33 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F2BAD1412B9 for ; Thu, 25 Apr 2024 22:00:32 +0000 (UTC) X-FDA: 82049423946.01.CDF9F8D Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2050.outbound.protection.outlook.com [40.107.102.50]) by imf15.hostedemail.com (Postfix) with ESMTP id D971CA0023 for ; Thu, 25 Apr 2024 22:00:29 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=AFNp6kcT; spf=pass (imf15.hostedemail.com: domain of Michael.Roth@amd.com designates 40.107.102.50 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=1714082430; 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=vQvxiengEpccv4Mkkia81lqqiMWkS6re/A6vdEXtbUM=; b=0ac1C3SYJjEgirnIrhn3ol9yVPmIIUyR2oNi00FGmczs+BNLNQz8A8XPClPh5iKhtn2uiU /riImGyCtnkeDAhf27qCgDFiz5Xl6SCE/hT5gaYKI2tvy4QOcUZVNADDWSVgwkC4LMgBPI YpcX1unLMVyFOLS6/lrv62CuUELtX20= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1714082430; a=rsa-sha256; cv=pass; b=b/rZdAP70v8+usFcf7Cco/G8u4FynBX1zu5AKZcRu3ikK88OK6+t7LV1Ip7GTZxyLGotmO kCp7fwydZ5jzXQzKp78Zq3NdrPX+EGLuBDZOX1n6+7DPpLf7Mf6s8FCNAnfbV6P3dm9BdZ Ff63PXeqO8pXbz9SxfFg3K+Q0itnIsM= ARC-Authentication-Results: i=2; imf15.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=AFNp6kcT; spf=pass (imf15.hostedemail.com: domain of Michael.Roth@amd.com designates 40.107.102.50 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=gxr23ZJNThA0xCdEa4t92x1RiSv4kZrTzVnx8TaGiacnpR0S4X3QBovvDPj1L1xFSBps6AVFrOxPG6opIXkaSgTHT6xmZErVmtk0Igmf+49IQMjTFI1nvcrGn0lyVYmcih4ZfiPgW/iRc8YpdqDfAS5hyEwppgBTZ93bbSuaDFHDjn13dYvC3oOQ6uIFj3iDMeY5BbULAHLf6LCqD7DW6gINPAa2+fR2/9lILnLXogYdMCVHzzLFdR5yY2H3YdZzLkliI+jYSmW9/cFttG99LIjRpO0ss4YB0W4ygs5I+8j9QEkeaAaOi330kYAFP5v8TK8zStxSWUrN7n7Q/CfQaA== 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=vQvxiengEpccv4Mkkia81lqqiMWkS6re/A6vdEXtbUM=; b=EMEQE8ZLYMsFX9OCuwfXcG6krdH4iEnTx/ET7DXWWfSUCG204uOKGvbOF46SwOYWV70V8UWPB9AyoHj9wnNfleSkhec3y9KmGZbjN4NWT28HjXlzSpdc2HotaUW2fBVpfuEHP5tyM6H2bSf8fM+BCaBSq1dKor98BMlYUWQjQ6dBToURDO+dy217NEr1hTDKQSS1+ElXvBT9gpy4Vr80OQryZXebafjpT5+uqSjsMw1srRdLWr39TZSWWEm8eWSypE+zdzbYXJCPl7ZxVX/aaxiRNrYsiuABYFpGwQp2wFUaumtAmdVWlxU0leqV51/38vje1OVmHHf3Wtitv9LDWQ== 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=vQvxiengEpccv4Mkkia81lqqiMWkS6re/A6vdEXtbUM=; b=AFNp6kcTtPPBXGohyw6mRD0D1Fhm5SQe47zArAq1Pa+Q5CEFufitvztQczniDdKtCLZBWfOJX44Fwi6VG4ZPZN+foLuc2XxmSkSVXnomWOSDcgWKAplagWCfTOBRY2dRKjpAK3MDVCeAQyX3SrrmDiv2ASEgWrxsVGBSBcrjt/g= Received: from PH1PEPF0001330E.namprd07.prod.outlook.com (2603:10b6:518:1::9) by PH8PR12MB8432.namprd12.prod.outlook.com (2603:10b6:510:25b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7472.44; Thu, 25 Apr 2024 22:00:26 +0000 Received: from CY4PEPF0000FCC3.namprd03.prod.outlook.com (2a01:111:f403:f910::) by PH1PEPF0001330E.outlook.office365.com (2603:1036:903:47::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7495.34 via Frontend Transport; Thu, 25 Apr 2024 22:00:26 +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 CY4PEPF0000FCC3.mail.protection.outlook.com (10.167.242.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7519.19 via Frontend Transport; Thu, 25 Apr 2024 22:00:25 +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.35; Thu, 25 Apr 2024 17:00:25 -0500 Date: Thu, 25 Apr 2024 17:00:08 -0500 From: Michael Roth To: Sean Christopherson CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Brijesh Singh Subject: Re: [PATCH v14 09/22] KVM: SEV: Add support to handle MSR based Page State Change VMGEXIT Message-ID: <20240425220008.boxnurujlxbx62pg@amd.com> References: <20240421180122.1650812-1-michael.roth@amd.com> <20240421180122.1650812-10-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: CY4PEPF0000FCC3:EE_|PH8PR12MB8432:EE_ X-MS-Office365-Filtering-Correlation-Id: fb010b4c-9e0a-4e3d-f3d3-08dc65731ce4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?6AWk+Yq7FwxtB4UzdgJ4YsPTFQaYrH9lmiaLNYwPib5e+aAR4+ONp7uXLWNT?= =?us-ascii?Q?s2S+MCFttYH2aXCyKnl70pSjss29jBtsGMWGfypWEWqlWJ2rDH1gB9eZ4gQw?= =?us-ascii?Q?PmadbzRPajtF/OPLEQs/fbJ8IifFKdSiGWsXphoSvUFNgVLFv5J744j46LGF?= =?us-ascii?Q?uRrKb8LwFPk7k6GCTjv2o65UtRNt/wK8N7vSFZHtmfG7aLXb3ivvsoS8OlDd?= =?us-ascii?Q?tXo0Z6Z6gfWS+C/9GTB6tKLByvMChtl+PRORUfJdSIxobmRwfpLcG1feq9wY?= =?us-ascii?Q?VbZ3rbjHd1CXBNgrpeTJfJXhzFIDtb2VsHePZEHDLuGu9ctJazd4HsH2q0e+?= =?us-ascii?Q?kl0f2tlqZYmhSrEYidRWolg813y6AftXeuWINl9vg+DBsR1V+BtdlEE4YnAT?= =?us-ascii?Q?hwzLgFBMhRlYBzpRaVrzQHElVx+q8zuwtUuKtFlIm8k7ZRg+i3BFH3GXPBqv?= =?us-ascii?Q?xaw16k77sZG4zsZy/cCqBnujWEv6ZPML/hh+5n0v6U1/a+6HMreLAkg8zaeq?= =?us-ascii?Q?o2LfN7s+O9vKD4KC9OLS9CnOhc0oBISG27rTdNiaosqBrkSyWx4WP1ZNaHgY?= =?us-ascii?Q?ytLkdogpVunjlsPmz5+RV7Het2qvf1TkTdDW73eaal5Lkv3OTYSqC3rGfjYo?= =?us-ascii?Q?u9F7ZLbnuShXRnvkBIhtmyNuJ3C583OzPR0LuTiZ7KLyu8w9uWakwNBHsweT?= =?us-ascii?Q?9VuRHBvj55PSP9Pmg9EcSYUpkx+G+V0GjJMrK2Gnuk/O1oXdL2rjmJ0fZ7W/?= =?us-ascii?Q?XD1Tm+eP2rG2q11U/ZccmskPEELk35WOmnc2f5kQQUq+Nov7lsWMQAGczCke?= =?us-ascii?Q?+bhd/8NNQdSIwPEas6RsyzcGK5F3T4y9zBhO1u/1LbPBvBf69GL/093SYpwe?= =?us-ascii?Q?6uKCpIjC+Y1tGoUYzTYBF4sZX+0ehTnA2vO4ztYfMgjOkUkujZMy03SmDURn?= =?us-ascii?Q?jpbEFuqXhn8ADq1xngUvzfm5fsYM8SgdIfSTdjw4vmZoTSNZo7k5SAPjIDpv?= =?us-ascii?Q?k0Plt/xYwgMgkvT3Qnz+mH60nfzDAPHlY4E0ALI/eEdUM9Jb5wM1ubYgF5Wz?= =?us-ascii?Q?PS9REi5v1eeRsHcbhvw8LRnwZgCVWNHW69iOJSK93CORGsdFSMkcWDFIf88A?= =?us-ascii?Q?2J8jGDuEePEwwJLbzKQ5SfvUE70AoYhbVWm8QyJaGLwZVggZr+TWutHNojjQ?= =?us-ascii?Q?EXdpw+zUZO602cdJzkX87dy8gJNkXfNBKSI6bSKdORauSthnHi/d5TNoJacm?= =?us-ascii?Q?vJ8pqS7e/9+puQJ7GaGEYo3aYxsdbNV+kKCMY5TaKmmae7C9yTruV0GmA+3u?= =?us-ascii?Q?lbgOhqeo614e/jeNFx0j2JrTct6H468c3jtghs1CmShETD+QTgX7Qiiu71w7?= =?us-ascii?Q?dJ/wlDPJ2naiD1TBXFl1gc7K40UD?= 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)(36860700004)(1800799015)(82310400014)(376005)(7416005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2024 22:00:25.9241 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fb010b4c-9e0a-4e3d-f3d3-08dc65731ce4 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: CY4PEPF0000FCC3.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB8432 X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D971CA0023 X-Stat-Signature: unmmti737ytrmuipryafojbyagffxnf4 X-HE-Tag: 1714082429-311897 X-HE-Meta: U2FsdGVkX18LjjfNysYQYmuQxuGWgxCgIZGDMu8zfNYHTfmyhZ4FmEjCxPQXja0aTVpdV9JcMe9NxJur8jk98pZHGBa5TSQaXM+IQDWvjCJ21tBeq8kbtKjTn9XxZ2n2R9Ir07uzO7tfFIgodWGb9nKb6pDajGX3LZv4q3l2RT3hNNZjYQtiuxFzTiNsDeIDUKcCkjihqTZd/DHpLirX98cfdNrhxaoK1P8toiqPJDkiTUDibIcDHQzGesKpfafkB/tDTB/FDQhcigZQhPQJx2raOcm6cWCOW9s8tC/JutatfjT44zEj57YXHJjy0Osm4q/DAy95WrdQpPOgzFGB99YjoN2wQ7JVTgQXO6RVcRfJ3//lMKwk7nDmt2xRPxrZ59Lg3PaB4VygVkyzLvlVo70NeI1dtqWnYqaBYg5TC21Bo14uq5oTEUWFEiTxJwWkVjCqIOA3AoRZytjN2577vWGSn3FnSlBAzhLP1TFhhGHQw2SBH1Q2lG5/JZ+kIYpEiPKzqSXOxlEaUIZdcMenU5pdy/Q4+PeIRIsZXTkuKkQ5GkhAbNU9O6pUEb/Lvg+GAxSV8NhsIte0GR/Lz0Spomkzm+nfXW9HSW6hfdefxxSU5FP7fAes/XpOXKI90cCh0vvvDXJNG2K2E8SJ2guI6x120ZQoSCs1nQ8Tpdx7IOT3o1xgQhpa9GyzF+FZswej0GR+D9BM7ECsMf2twVnGKjC+a8JW8hfmhmtqt0v7R+uDUIlID2x73IQlct6nQVjp1l0ZFLtXMdW18EmPcdwwd/DQHQQbX3erT6ik7nrATwuwar2DWGqMK5DU9MaiN1Z/s0XZvXYrDheHLWABrrl7jINP+Dh4ChCisDfovOQwmNoXrS/+IM1wWTUF0fhdwGswUaxVugVP/PuN7VTnd/DH2VVC1X62KYrKDdAl8u3SxCrOul1l1X5CdCicETurnxo8PIobGr9ZFYiTKKvh7cU gqGRRDwK zNRk4SqHgKw+QnWmJTIhdp57Llq+rqmHXjaUo7sQXIMrz6lKpQKoovCL+0yN4MiAkljBYxgAL9Cpkg/d5cFmzmCOyYjFggH1QsCIvy8tQvhomZSrDESmsNthDFqKQblnWgFdijdJxJdX5Ardlpsd3WEPrftsaOYARfkwkr7KDRlrylR7o6TzwDIKwjJuccP2YFbSpDWlYaYN/48v87gKg2etXNZdI5+huTnOLTRAIQxfsABbThNrWFe0b2Xm4tsvoUvCj07D63GjmSguIaEnFNdMsDD90pTIi6kp4SxiJt5IEreg3gBuRyiN4UwGaMgNJ6EuBE7BeKAMqWIpyCUqsG1+URIkwsisO2AJh5fzxgkrFfzXVwf/8aSjy+HK4jkEtG52CZWEiqsUqkXJC7lNNJmy7S03OCnj4ktBhZJBjXDJpQQqyEdQNe9ES6h9dz6kevqJi X-Bogosity: Ham, tests=bogofilter, spamicity=0.003704, 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 Wed, Apr 24, 2024 at 01:59:48PM -0700, Sean Christopherson wrote: > On Sun, Apr 21, 2024, Michael Roth wrote: > > +static int snp_begin_psc_msr(struct kvm_vcpu *vcpu, u64 ghcb_msr) > > +{ > > + u64 gpa = gfn_to_gpa(GHCB_MSR_PSC_REQ_TO_GFN(ghcb_msr)); > > + u8 op = GHCB_MSR_PSC_REQ_TO_OP(ghcb_msr); > > + struct vcpu_svm *svm = to_svm(vcpu); > > + > > + if (op != SNP_PAGE_STATE_PRIVATE && op != SNP_PAGE_STATE_SHARED) { > > + set_ghcb_msr(svm, GHCB_MSR_PSC_RESP_ERROR); > > + return 1; /* resume guest */ > > + } > > + > > + vcpu->run->exit_reason = KVM_EXIT_VMGEXIT; > > + vcpu->run->vmgexit.type = KVM_USER_VMGEXIT_PSC_MSR; > > + vcpu->run->vmgexit.psc_msr.gpa = gpa; > > + vcpu->run->vmgexit.psc_msr.op = op; > > Argh, no. > > This is the same crud that TDX tried to push[*]. Use KVM's existing user exits, > and extend as *needed*. There is no good reason page state change requests need > *two* exit reasons. The *only* thing KVM supports right now is private<=>shared > conversions, and that can be handled with either KVM_HC_MAP_GPA_RANGE or > KVM_EXIT_MEMORY_FAULT. > > The non-MSR flavor can batch requests, but I'm willing to bet that the overwhelming > majority of requests are contiguous, i.e. can be combined into a range by KVM, > and that handling any outliers by performing multiple exits to userspace will > provide sufficient performance. That does tend to be the case. We won't have as much granularity with the per-entry error codes, but KVM_SET_MEMORY_ATTRIBUTES would be expected to be for the entire range anyway, and if that fails for whatever reason then we KVM_BUG_ON() anyway. We do have to have handling for cases where the entries aren't contiguous however, which would involve multiple KVM_EXIT_HYPERCALLs until everything is satisfied. But not a huge deal since it doesn't seem to be a common case. KVM_HC_MAP_GPA_RANGE seems like a nice option because we'd also have the flexibility to just issue that directly within a guest rather than relying on SNP/TDX specific hcalls. I don't know if that approach is practical for a real guest, but it could be useful for having re-usable guest code in KVM selftests that "just works" for all variants of SNP/TDX/sw-protected. (though we'd still want stuff that exercises SNP/TDX->KVM_HC_MAP_GPA_RANGE translation). I think we'd there is some potential baggage there with the previous SEV live migration use cases. There's some potential that existing guest kernels will use it once it gets advertised and issue them alongside GHCB-based page-state changes. It might make sense to use one of the reserved bits to denote this flavor of KVM_HC_MAP_GPA_RANGE as being for hardware/software-protected VMs and not interchangeable with calls that were used for SEV live migration stuff. If this seems reasonable I'll give it a go and see what it looks like. > > And the non-MSR version that comes in later patch is a complete mess. It kicks > the PSC out to userspace without *any* validation. As I complained in the TDX > thread, that will create an unmaintable ABI for KVM. > > KVM needs to have its own, well-defined ABI. Splitting functionality between > KVM and userspace at seemingly random points is not maintainable. > > E.g. if/when KVM supports UNSMASH, upgrading to the KVM would arguably break > userspace as PSC requests that previously exited would suddenly be handled by > KVM. Maybe. It's impossible to review this because there's no KVM ABI, KVM is > little more than a dumb pipe parroting information to userspace. It leans on the GHCB spec to avoid re-inventing structs/documentation for things like Page State Change buffers, but do have some control as we want over how much we farm out versus lock into the KVM ABI. For instance the accompanying Documentation/ update mentions we only send a subset of GHCB requests that need to be handled by userspace, so we could handle SMASH/UNSMASH in KVM without breaking expectations (or if SMASH/UNSMASH were intermixed with PSCs, documentation that only PSC opcodes could be updated by userspace). But I'm certainly not arguing it wouldn't be better to have a guest-agnostic alternative if we can reach an agreement on that, and KVM_HC_MAP_GPA_RANGE seems like it could work. -Mike > > I truly do not understand why we would even consider allowing this. We push back > on people wanting new hypercalls for some specific use case, because we already > have generic ways to achieve things, but then CoCo comes along and we apparently > throw out any thought of maintainability. I don't get it. > > [*] https://lore.kernel.org/all/Zg18ul8Q4PGQMWam@google.com