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 7982AC25B74 for ; Fri, 31 May 2024 01:23:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 110E46B009A; Thu, 30 May 2024 21:23:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 099726B009B; Thu, 30 May 2024 21:23:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7CC86B009C; Thu, 30 May 2024 21:23:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C58696B009A for ; Thu, 30 May 2024 21:23:06 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 82C80160F22 for ; Fri, 31 May 2024 01:23:06 +0000 (UTC) X-FDA: 82176942372.13.FED0D0D Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by imf17.hostedemail.com (Postfix) with ESMTP id D49A440003 for ; Fri, 31 May 2024 01:23:03 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BEWGgcJo; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf17.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 198.175.65.18) smtp.mailfrom=binbin.wu@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717118584; 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=HVh4VBwFJ1+sNTLvu61T9g5pKQyptEaPyhKqSmRcnYY=; b=AON8mgJiUMeKwoFv8OxKiWE+ePQcU5NTnwObBeAVE6CfxYSUW5JlZ0CDvMS2GZgsK+x4Dx LLC6GLYhonuArYRyUW13rcWcIs1pEJ7uNBLPWe0OubHKeZsshLO3w2hwum3zVOJJnmtSFF LZ2+jLU+suIaIKnI6lCGn6MHkBhGurM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BEWGgcJo; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf17.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 198.175.65.18) smtp.mailfrom=binbin.wu@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717118584; a=rsa-sha256; cv=none; b=dmPkPjK2J/8BohGc4GY8zk1FrH5uihDS7vszOsyWWxuo9823Ja19iqx2vhJ3pS3ajVCwCM 2wJKhcSghp57/59aA9SA5s4OL7D2jwizbX2UNhLp3KAkvfkO9JH6HyoMH8DtjHg8OBDPzS W24vVxWSTBi1freynTNSP4TXTIBytZ8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1717118584; x=1748654584; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=nlJxlGmynhU7KREnzEbXx6DTgU2f7pwNSzsU+KcONRc=; b=BEWGgcJoNNJfdt5dwV+poxZ4EGboIuUWReCTRrstghatcbc8yLQuokpL YghdN+8CFtjkVn2gLh5oQrtj7utX+8Q03jUJW0eMQvqZ/TlV9o3KUJCpW A2E+yEpco+sdeF4OzD6/JVEsUSsb8FBtEpa7T4luv4n94OFZXV3H4Ln7t iO9AhQTYckrWc5a1wjEVWbtrbYxAgooxnZ5i2sGHhYojuP4zwSxXObpaR X1Syr2RokLh/qwS9zJgGsanpBIDEQplapAqwmn0BlYb1c5C55/Fz8i766 njCCfdj3m3V0u+7xxlmyhZsHnfbG0zyLJGjM4cH6c9uYrIGXTkHFyPrwH g==; X-CSE-ConnectionGUID: EXRGIQ6oRySE4vNA+7wwgA== X-CSE-MsgGUID: njDHR0aZRpuAMMW7Qfu4/Q== X-IronPort-AV: E=McAfee;i="6600,9927,11088"; a="13813787" X-IronPort-AV: E=Sophos;i="6.08,202,1712646000"; d="scan'208";a="13813787" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 May 2024 18:23:02 -0700 X-CSE-ConnectionGUID: JYIBlf2GTXWPxN7j2kb+Tw== X-CSE-MsgGUID: 0jVmIHa9Re2o9ypgdTRyTg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,202,1712646000"; d="scan'208";a="67200458" Received: from unknown (HELO [10.238.8.173]) ([10.238.8.173]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 May 2024 18:22:53 -0700 Message-ID: <3999aadf-92a8-43f9-8d9d-84aa47e7d1ae@linux.intel.com> Date: Fri, 31 May 2024 09:22:51 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 09/20] KVM: SEV: Add support to handle MSR based Page State Change VMGEXIT To: Sean Christopherson , Paolo Bonzini Cc: 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 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> Content-Language: en-US From: Binbin Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D49A440003 X-Stat-Signature: nwxky4xhjr9kpp7jzjonpcop6ruku6tk X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1717118583-674468 X-HE-Meta: U2FsdGVkX1/3UbEE8b02Z5QVF1blGleLWipT5hDVoVdAH9xY/Ig24RPw0wEKaJUjpbmiADoiKPKtQUa1LeqJVJcjC8eoMRl7CzC6SLC6PhQp8tzIQ5uN6FVLpksIBr0Wu7NKIcvwx/5S2ovsg29QutQrjlx4qMefCRYMrTv9+fkLAldG6Rt5LLCEcj2voL5dcn3OcGmoxOiBHtXW1d7aXPgmEXhESDehTKLfmv6VitaTIqFxZ+xivhLEBroEFPfdETFCwac2wy+5HUgPbOjVFS/7lePu9B74cpr5KOg8uDrxfQiS/TIIVd40T5JQpVosND9KBOu9OU4lIm7ixL34iCrbjDE3JQzAWwZPoP7ssSsOe1QcVwekvnils8pvnQGAe2hP5JqNnCjun+hXWUe+YZLQ7ToDbiQ1EjlpKgxqIougbFGoM0O0rQX/RRshnaRZCuGBi4ciiiJ4JNTZhNXFAiGVpnTGFN0fJBiLSt4YiEe/fKhesFFKWZFz7fPXm304TPO3ZFQIHILPq3MxoNoOPrLF4x0GyLCpXv3XbEnjMUOS4rfUPJfRFkJYXK5GUzp+H7MPDojsZX/AHpmlKRstWQVHV6w422RlpuW/io6D3PvPSHP55Ywyp61rW0X4KZ3iPRcP5i3kOcsK9zjBT5MelXdxJVDNJd7bGogF9W59VuipvMyITLsuREJFWfMOb+R7EqNtNxF1+surruxQjlu1QzYpopzvkX/951WpDdFgD8/3ntYLwsoogjvoCS68xNwj/Ky8zSZck2MpG+m0IlMBiFHKNOs14nmDDM78qPnt0UdTqJMVSLG/6FsPeZ6mFHyjmsZVc+IfV/RnH2zYwg5S3000VKQBmEvtkKagcQWakvIa+0BkWr8wmgnldPum3LibEEB0ypIzBlSmZlssenz4IeVq7DhlFHM+c0ga/wUuY7iPmMuMzFRFlx6ZXrY5PoGXLRvqD0IGriSsua3hZ0v NdDWNbcI 8wVPq1VGN0BJH+bKof5S9OsxwFjeW9kcFK6jXOGaAoBHGUSO7HrpZrlMUcMI9nmCX86za2sziNkwbp/p8fiW4VV7locwZwMTkeC5zGUPK2ZdsPVXuvTTYVJGLdcrYciOTjt21+x5BJnxb2Wg85/a9hS59KHZa77EGMIbWxinaFozbD4PFJNAoHZsCVHNlBGH0G0RkkNJXFRO+b3tJ8CuwCYcA4Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 5/30/2024 4:02 AM, Sean Christopherson wrote: > On Tue, May 28, 2024, Paolo Bonzini wrote: >> On Mon, May 27, 2024 at 2:26 PM 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 greater >>>> than TDX_MAP_GPA_MAX_LEN. But at that point you're effectively done with >>>> the entire request and can return to guest, so it actually seems a little >>>> more straightforward than the SNP case above. E.g. TDX has a 1:1 mapping >>>> between TDG_VP_VMCALL_MAP_GPA and KVM_HC_MAP_GPA_RANGE events. (And even >>>> similar names :)) >>>> >>>> So doesn't seem like there's a good reason to expose any of these >>>> throttling details to userspace, >> 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 switches. > >> 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 attribute, >> establishing the size that will be processed in a single TDVMCALL. > Is it just interrupts that are problematic for conversions? I assume so, because > I can't think of anything else where telling the guest to retry would be appropriate > and useful. The concern was the lockup detection in guest. > > 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 that, > KVM could use a much smaller chunk size, e.g. 64KiB (completely made up number), > and keep processing the TDVMCALL as long as there is no interrupt pending. > Hopefully that would obviate the need for a tunable. Thanks for the suggestion. By this way, interrupt can be injected to guest in time and the lockup detection should not be a problem. About the chunk size, if it is too small, it will increase the cost of kernel/userspace context switches. Maybe 2MB?