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 8EB28C25B75 for ; Wed, 29 May 2024 20:02:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1FB66B0096; Wed, 29 May 2024 16:02:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CF446B0098; Wed, 29 May 2024 16:02:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 897226B0099; Wed, 29 May 2024 16:02:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6BBE76B0096 for ; Wed, 29 May 2024 16:02:11 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E57DF4014A for ; Wed, 29 May 2024 20:02:10 +0000 (UTC) X-FDA: 82172504820.07.F6718E2 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) by imf01.hostedemail.com (Postfix) with ESMTP id 0ABFA40023 for ; Wed, 29 May 2024 20:02:08 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="m7fB4yK/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of 3v4lXZgYKCGoaMIVRKOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--seanjc.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3v4lXZgYKCGoaMIVRKOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717012929; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HB9I1KtyGLGWJZbJtvz+lEDv77A0FrVSDAPAJPLn2YA=; b=qbPm9XVyQRTzX/yv+yYWcc0Rw9jnFzhDt5jv//1OzDDEyK0XSeUPU50M9ZYS+B/Epr3F8+ m8r7q5Qg2/pdmJ7cFnXEwHuuPfLlxS2CUMeBMM2NfACnlqX1RoM6PEq65slMbWQb9pVLFU NRla/J+3LC28SKXv1zAPh4IBpFRd4K8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717012929; a=rsa-sha256; cv=none; b=sZoPO/BTBXCOkXMxk2VaBdwjp5GcBN3RU98shqrfAF+pmnt65I1bNJ19u5CezEXF3l/4wt 5hzRlfGPVO+ZPyU3Ha03h28bYIOYFzT/mmnkvHOUqj4BQz17x+8fQ3IkrtE7z9116kN6gW 3SoG88CFmM53t9YhSdOzB5eSu8zGrNk= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="m7fB4yK/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of 3v4lXZgYKCGoaMIVRKOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--seanjc.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3v4lXZgYKCGoaMIVRKOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--seanjc.bounces.google.com Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-649731dd35bso142534a12.0 for ; Wed, 29 May 2024 13:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717012928; x=1717617728; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=HB9I1KtyGLGWJZbJtvz+lEDv77A0FrVSDAPAJPLn2YA=; b=m7fB4yK/g9x4Z9GDFSuVfBFjIZRCYdtVHnUGn8wjoRqHKxC+eS/+xpU1C2K2d8N0KS Kj04odqsZmk4wuMuCkHhAQ0CYzyhm42rQ9dcmjwq4T7ONHUhVNLzZT1BTc61CNibeJVI /jjgAr/gyBJZEsaUbhv7s+TP74N0hnpip5meRODjatY2fMlUQQz7O/nWnBQhAu0egHfH 2MKat2/MvOAD43lKd+TjU0gebnYuScdA8lLkdCe69XfD9mYuLmb2sZJdJVgAzlkGlr+Y fPM9Zoy6EQZHhqRzd8uovrxSkCCw/DvgXfUYVQxhfdHVQmS3nvgmlvAb6eR7CSdSIrfa Kq6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717012928; x=1717617728; h=content-transfer-encoding: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=HB9I1KtyGLGWJZbJtvz+lEDv77A0FrVSDAPAJPLn2YA=; b=fDornBPFUH4uRRIECaUo45wLoP2+cuMFl96nSVO4O10DA3ddNn6QFPrKil56z+Wlf2 EluYhbdMUbZuRUQlun/bfuRmMEIf6jutrR8+ruLV0/tarAJRNos2tr+txEGvdGww4wTQ 5MM+6fbQy3b28rLQD+Fr9t993BNS/UO0EdZR2kNkxesX4heopRIYXQ2rNo7fK4HzGrkw 1hGZ7sg9qrbat7oBOC9LgZa08TDl+vJ4VCUpqieAMClxaZ6JmnTDXNV+i/JEOqSg5CrD mNjbZqB5SWWe2PYbWF7vSY/tVkr9jmCUbxuKMxXFwFH3EWlsTeFRSeVWdvUirKcgnwCT mhGw== X-Forwarded-Encrypted: i=1; AJvYcCUzAaWsGaN+APLjEP3rz/J0hKiL0g0yAALVvx0DJdB77Qq8ivDsZYstGVTN2ctAWAPSIsysrZhWNqRJv/FVUcL+w9s= X-Gm-Message-State: AOJu0YzJeVGHDpvD9rHd4uvIneLoTukVB9dZssGzeNfIW4EsiyT84X0S U+WlcC6xn6FjJeLV8uzaeo3DNJ0wdF22TvgirYi9P8uk3+quzO4lPQEJ+SED9EJw8Z8vS7papEN HAw== X-Google-Smtp-Source: AGHT+IGnVjGAGUdS+QWuXtFD6JYVk48kHHGOYEmxpJY5fF1LGZtFCwusKyw4nxPICVEtyh7y/Kks5wf6ja0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:1258:b0:2b8:9aac:2b04 with SMTP id 98e67ed59e1d1-2c1abc659ddmr252a91.5.1717012927588; Wed, 29 May 2024 13:02:07 -0700 (PDT) Date: Wed, 29 May 2024 13:02:06 -0700 In-Reply-To: Mime-Version: 1.0 References: <20240501085210.2213060-1-michael.roth@amd.com> <20240501085210.2213060-10-michael.roth@amd.com> <84e8460d-f8e7-46d7-a274-90ea7aec2203@linux.intel.com> <7d6a4320-89f5-48ce-95ff-54b00e7e9597@linux.intel.com> <7da9c4a3-8597-44aa-a7ad-cc2bd2a85024@linux.intel.com> Message-ID: Subject: Re: [PATCH v15 09/20] KVM: SEV: Add support to handle MSR based Page State Change VMGEXIT From: Sean Christopherson To: Paolo Bonzini Cc: Binbin Wu , Michael Roth , 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, 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 , Isaku Yamahata Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: en1ihkn95pin59j4x8557d3z8fhzgpxn X-Rspamd-Queue-Id: 0ABFA40023 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1717012928-445860 X-HE-Meta: U2FsdGVkX18BSKGfKWoDZldbX7675aft0Jm5pFKKmiOH708AAZUcU9Fqh4QzbwEexLyGI22eL6IlBOgcnN/+XxzH9AbLqqGGhfEwyyVixccFfbQcgWYMmy2iLYLhYznuPJc3erc1MjTISvcwqa1lkWRwxlvrctInSrgP5rRt0/kLtnPpIfKPBP9BO94mS3VsFtq6gxpPMmn9TeMXFzftuRj5R0tKuZxXh5c1g9KWoQlnW9G1d1tIQ6Mi5XUMsMkqOXjxebvKeI1sQVLwIOODPx6Jz4zVYZb8hvHv5V2/tjWckkX1hudDk5V+djgkyNME7XdcgmbH4mCCiRsBLhKqgr/spgIuVx6mHeEgODLjDD0uUl7lz7+QVIev8t9lnQFabjSWeXKCDA6eWCOzfHfA2FHH/1ekjXi14ZVukdS4ieV6ePP3NJUUA8gmirumQEwhM4p+baJd4N1JHn2f4wolENdx3h0tkWxdJw1qV9SidoN+JeaB4oDRphtlizVBZr0Nq+5BhWcsJMzuteA8dHQr4CH/kiI7OUoZCBKjDiL7bmMxa8M9OdlzdxCbwKXnLp0EkI8vgdhBa4Z9xfmFBGAmaQoeO01ATYENLSBYSTfpfpVwspR72U2JZY7t0Q/HwMrH/zIld6/OQXH8UALW9l1664gp9Ic4xlC1p33DawYXCV14Emnk1DUYH3DjuXBkd/YM+RXM1D7pSwV+jLv86+sY75HlJ6bzpEHxLzmstRuSiYG1P4mDdhAsXUwaYx1YhEwdfI78UCY+Sxyj2lBh1aMtgkC6Oi0u/15CDpFJv3OaoNsXvBL8pcZeW4s6ujA53G6xCLMf/SwBEkr7lzTfboxAmil9Xh0UUt5m1+UkkGgVURm3my+6YcnzyxdvwPxlPJbJ4j0bW3aj7ijc0D59MrZtkg5h5MIn8bxA4TX7/14Ja9syBjNIauAUWcYy/wYJeSl+MM2t6qzfbn1zP6MJ6aA DbTwd2MX H/a2myMdPXAEN/uxJKKRkimej8JYDs/iHmhU6KX3P51gnE/6n7UsL7CTXrnzvGGemUzkZE/qg9/nT+IniOwwyrr5FwrSTgt6doPqgiR+ybafOU3EZ3H6VhW3MQnOiQaWUsW7GV4QEFYcTKnpA2Y58o0QMrPTEGTR/bMMuLl8M156qhjidDh8jZ2iYDOAEx6VbvcDAzr/+k+wpiGqJPotSAFMowPQFdXkBNaDMNRnCEqzp55xB1xn9XtaACla5FR7jEHChBDZXCBTCDY02EON9W9m+ve06oLQ4O/l98DVSQBTJGJKKCdWEZ63d9z4gYUyF5fZU+P+p46CYMcl/woauuFvywfTkbCeJ96H7VcJxTNDqgZK9tbjZNFL3V2dYVMRb3aQVK1zDEwLfrXMBlnSLEoIIrc1bJ//02R97ZWUvJ6lf5caKVBXAPbxEVMOqe6QH2wTt1r150AdFC744X1X3it3ikAUv/HiRy11f9ItDVLSmiHI4hIdzVrMMfGaJyfxunTXui3HoDZWg6Qg0vFoCLJPZz7yMA8DkaKt2Zz4YQc3R7bHuvbDhCWLIjfdR0M4fujWOVnT6PXcY/PfV2grzNIa3Ex1akrPhCqGSO3P8HzcILQw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.032096, 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, May 28, 2024, Paolo Bonzini wrote: > On Mon, May 27, 2024 at 2:26=E2=80=AFPM Binbin Wu wrote: > > > It seems like TDX should be able to do something similar by limiting = the > > > size of each KVM_HC_MAP_GPA_RANGE to TDX_MAP_GPA_MAX_LEN, and then > > > returning TDG_VP_VMCALL_RETRY to guest if the original size was great= er > > > than TDX_MAP_GPA_MAX_LEN. But at that point you're effectively done w= ith > > > the entire request and can return to guest, so it actually seems a li= ttle > > > more straightforward than the SNP case above. E.g. TDX has a 1:1 mapp= ing > > > between TDG_VP_VMCALL_MAP_GPA and KVM_HC_MAP_GPA_RANGE events. (And e= ven > > > similar names :)) > > > > > > So doesn't seem like there's a good reason to expose any of these > > > throttling details to userspace, >=20 > I think userspace should never be worried about throttling. I would > say it's up to the guest to split the GPA into multiple ranges, I agree in principle, but in practice I can understand not wanting to split= up the conversion in the guest due to the additional overhead of the world swi= tches. > but that's not how arch/x86/coco/tdx/tdx.c is implemented so instead we = can > do the split in KVM instead. It can be a module parameter or VM attribut= e, > establishing the size that will be processed in a single TDVMCALL. Is it just interrupts that are problematic for conversions? I assume so, b= ecause I can't think of anything else where telling the guest to retry would be ap= propriate and useful. If so, KVM shouldn't need to unconditionally restrict the size for a single TDVMCALL, KVM just needs to ensure interrupts are handled soonish. To do t= hat, KVM could use a much smaller chunk size, e.g. 64KiB (completely made up num= ber), and keep processing the TDVMCALL as long as there is no interrupt pending. Hopefully that would obviate the need for a tunable.