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 1A964C19F4E for ; Wed, 24 Apr 2024 20:59:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E4F76B0134; Wed, 24 Apr 2024 16:59:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 796106B0136; Wed, 24 Apr 2024 16:59:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 635E36B0138; Wed, 24 Apr 2024 16:59:54 -0400 (EDT) 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 449AC6B0134 for ; Wed, 24 Apr 2024 16:59:54 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E585A16024D for ; Wed, 24 Apr 2024 20:59:53 +0000 (UTC) X-FDA: 82045642266.27.3C70B6C Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) by imf20.hostedemail.com (Postfix) with ESMTP id 38CE81C000C for ; Wed, 24 Apr 2024 20:59:51 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="Ss/FkT1M"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of 3xXIpZgYKCIg4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3xXIpZgYKCIg4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713992391; 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=8U1TRrKJi3x9eg5Tfok1QV3PlGCm0SDXSlp6I7iPxGE=; b=bFpwEgZUrhvDtDPehkOGWoE2JjbymOqrCCkLTnsZJZT9EMYMZuLlLuCI78B/yZcIzt8rf6 Os7j7HWe7+0039X7VzEtYrMa3ldVi6wsksUTYMu7CtaNyMeIzhbs/Ycb+UG9SJ/7Y1bnor CBez0QC5heis0vLB8pX+XG/OUaVoE0w= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="Ss/FkT1M"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of 3xXIpZgYKCIg4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3xXIpZgYKCIg4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713992391; a=rsa-sha256; cv=none; b=wPPYsqBc/k2ufVyqE+a85xPVhjeNheyjK16ZCosgT8nKtzk6pq8eaDW+81g94MNz9mQ/K4 ItH8sTlZdu/Sl8WHfQm3e6Yhe5GYwlMQ5i9yiV/5fMTJMmhVlhJrPkeA6aJXHLCZt9auz+ ZDmPtoXNzfnqdp0OCEFQigCtbfrdJD8= Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-6ece5eeb7c0so311426b3a.2 for ; Wed, 24 Apr 2024 13:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713992390; x=1714597190; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=8U1TRrKJi3x9eg5Tfok1QV3PlGCm0SDXSlp6I7iPxGE=; b=Ss/FkT1MoaC9xMGhYDrfaJicSwLfVewOXfF9bjy7nnDhNssg8UBxICxMq7kvDUA/aK BLgnAVdS6XrQFJBslG7B7eX44VFrloTwStl0f6RarCz6NIIvmdNHHwe6QsBuGiBdbd0C oOLXtGBI3eElVLiDYZZmQeQnbn6WtTY1ToKngIJLIRoMBp5wcWp656C4kFdv8Z0/I3qr aW1IWz/Z5w+vahS91pMkqXrQMIseq3ypk9Akokr5/bSkRs+O5AuOLjaWcaDeZr1/1VOi 9OjN3gi+n755jfCebr0509LObjLdHriTbc4apDb2Wu3feMDTzo0IdgpbI3OMMvshIpHN 7ZEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713992390; x=1714597190; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8U1TRrKJi3x9eg5Tfok1QV3PlGCm0SDXSlp6I7iPxGE=; b=xEUm5DmaxABdUwZE08f1BywTxO7jNZYFWqoAPa7qtbdL5yTOw8lNMFtg2Orl+dtVS+ zEFp4dXBp43Q+tNxy5bu2BwAXIyBAEayr5iFdo5zvN1dKc+genqdamMhMKxyr/9SmcNV 1N4SSPtnXEdrRQX3adcyy9Y64TDGz6dzI0CYr3rp55cJc7GOj0xd08odTObY4bnHinMY o3EDKcyJa4UJnKiMUWcTjf4TVv2KE5FV5SDCmJ+F6iYHjpITSfFwExRK6zaOsNcUlkjD q4goVBaAYaC9GBEaWTG/xli3Db0jaSB7GCuPsChPMOJElBN/dpEgXoh0EnsAX3xRs7Qh wGDw== X-Forwarded-Encrypted: i=1; AJvYcCXn4DOvHGbkx74YL1Qb2y29RItJJRtFTXnNgP2WA7OSKLlAODBtfVSSXGL2KiVaXN+AYZeXxeDX1A867VcDeBFAG94= X-Gm-Message-State: AOJu0YxWGP8cjIhDt3kOT0uqgDK6DBsLeMD2CNsUz/8dp9WbXRDdmlnc F/p7IwHjsNGTuYOo2f+SXPu58yacvMxlLbhZNN+sP8iMUgcAedcv9yEEHzYdhEup4iRrM3cz/Dh rLA== X-Google-Smtp-Source: AGHT+IGmpsjpffCacAgU+oA7c6LytEyPptV84YPXAIS11abUo+sjJaZSSsVlO+4Jy+7xcfCJfVr3EYbcplE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:22c4:b0:6ec:f18a:2783 with SMTP id f4-20020a056a0022c400b006ecf18a2783mr446579pfj.0.1713992389985; Wed, 24 Apr 2024 13:59:49 -0700 (PDT) Date: Wed, 24 Apr 2024 13:59:48 -0700 In-Reply-To: <20240421180122.1650812-10-michael.roth@amd.com> Mime-Version: 1.0 References: <20240421180122.1650812-1-michael.roth@amd.com> <20240421180122.1650812-10-michael.roth@amd.com> Message-ID: Subject: Re: [PATCH v14 09/22] KVM: SEV: Add support to handle MSR based Page State Change VMGEXIT From: Sean Christopherson To: Michael Roth Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, Brijesh Singh Content-Type: text/plain; charset="us-ascii" X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 38CE81C000C X-Stat-Signature: 5mquzbt98zpbads8c8xtmnanh5qs5kaj X-HE-Tag: 1713992391-371131 X-HE-Meta: U2FsdGVkX1907ETvYYCd5TgqOtysgH4KSS3FUJPIKKBVGnU6BXSKztFPAhqZJO7bE/lQmS4HBTfYV2Gf1+5YIFPnL5tkvuZCenrE/HJqlXWZphdEOm7nkPV+zYziv+crpgh3BN18hQVE1DAtOSzmkEA2X6FtHm2MuMFOqqN/tI7tVDBVpV11Ub5dGxL1tmMV+mGPDLW3sQvgilc9DnKmfxcP7lP2fDEWYSCagyvBvDC9o/NBc0jDS3Dj8eTK2CKcvUIlyCxL/Jeedz9I0TpUD70WROZ3bn0rMQKBfI++SPXButQyC7PsC7v7Pv4bsdUshUOfO+6UZOpkqvHa/nDUOnR5odZt+RTHnqfuAx9Wi37NDkUbT6L3Pmvl32sXYEPm3t026DEbGq7xiBWPhLCfEQHM7TyrC8ePjKVeEg2TNryPNNHVUkq+uyPC1hlXYio6b3eY/+K5UoKz+c5K4K5yVXCQTx1Rl97cUZBN3o2Tj1rCmTAMpqA/67O7TqptTFaDrChhUqneuvucwTCFc/s0WjQbAHGsDgFsRVkYHR/AOhFZnEwKmaRyknbrgqOW28Cq8EX7+ymlDOcyJYltZScfMcfjJ2Xz1Ydhkue8hzNhMa7ZmbAM/PJcieltYXp4WC0bU71hGgbSjBu+1jBtRRk+tX2FyVLFEc1fuXIDY+wAiuqZdaNgZ7OFEJbnrOVN1kHp0IBYrhqxhbf4li2J2s5cfHQhnLHJSHYSC0MhbguTe7hJ3XYKTtCQGF1gxlu6rDmC5oY+rETqYb5bbT2a8rVo5RZ+/TgBgGTIy12mNyRGooERF/ZItQW+U1HNKOT5w5odhvj/0N/HaB5qFKNRYS2g+EZqWCqONeRQo0uDuPtTE7TJzllSXmXwKow7awRZ7T8OB5mIDQTKbSDeguinZzba2/G/CfF/TfYmB5b7tgo8dn8kOV5KCre/uerGTHkbJTPdGjb8R3iAIRNyp5HPuCY EWacwcui 7WQ8f1Pc12Eer/IIThF1xtk7933cXLbCZm/HgXG9UUaYydl4uHX3AgW9A1AP/4PcRD6Ofe557/8M1BwgZdiBn+7JQE/IH0dqNQlvGQ8nv2NVXcn3kkOyaoI0eaWunVzhHmJ4ql/q4nI+LPu77kStcRQlZhFoWzX9nGRJb1Knlf4LOycAwlSuhhCyo+F4MALsB/25A+6p8eEwz8ovySu3bkkDlzXRxHKMEVnZKYGHb0N5FKVAaDzmggytzwyVvZZWEdtX6hXtu60SAiT8EajkdjUncZxob0XfiYeXc4bADfCm5ARqY0cIJbZK2qTEGm6riLHyzyhDwYrsALCA+pw7+6aDVZ2n2YgiCggw3Gf43kWwv2oobG9TqNZgZK3cpK18fKYiX73Gitfztf9elnjcQVzbNY7ON34Q/oLjc3/P02LXUPMVqO27NTOgwury7Q9icHm5yqnr7yxrpaLwqxv/kQLpgvsAbU1lS9rlcmiigxuSHousFHZeK9fJYqoaIZbH+AZ7vNMstioIOBCnvy/MeOhhgdUyfTfPkC4pMCX81zZFq3IEApWNb42DgVoD6304qgfUgnN/I/aD/VTtBrvjnxKOdBo7/oKiVuIS0ZungsvGusw9mEfkurWOJLu8QykzVZ/cNSC0Q6MwTpH70/FMmSPtJqHbGufMcB68S X-Bogosity: Ham, tests=bogofilter, spamicity=0.026771, 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 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. 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. 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