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 4B758C25B10 for ; Fri, 10 May 2024 17:47:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D83816B0110; Fri, 10 May 2024 13:47:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D341B6B0111; Fri, 10 May 2024 13:47:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFBD96B0112; Fri, 10 May 2024 13:47:16 -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 A31706B0110 for ; Fri, 10 May 2024 13:47:16 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5FB734054E for ; Fri, 10 May 2024 17:47:16 +0000 (UTC) X-FDA: 82103217672.26.799F376 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf09.hostedemail.com (Postfix) with ESMTP id 1DCBC140006 for ; Fri, 10 May 2024 17:47:13 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kW7ZXFBY; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of isaku.yamahata@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=isaku.yamahata@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715363234; 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=pZaIQ+KbNxDAbUdLheFVzOn8pZ7fQfKcY/iFqYAhBsg=; b=6nIne4IUNB2E0p6Al79hfmimxr3XEksmstMrTR2SHZax/dwXTK78sN6qH4xVtqNxYTjPid ICmWyOe9H31wTIyI2YuaYHO63UH9lr7DfEQmez+VqMMfwxpSQU9a0Hl7W3dyZJ6p2mPpwL nP2ogC+7xCFBmy2mer8QhhoSHnZPpZY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kW7ZXFBY; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of isaku.yamahata@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=isaku.yamahata@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715363234; a=rsa-sha256; cv=none; b=s8TxqhfWIvdw9tloCvex2oOKC+3/n213IAlcafSNSqoQSkR0NR1NIyQ1keK9uqxcVWxJLc MCLVZRqMUazuET57/Jf1D02FydtYDe65T8j6YocuXLUdqQ4B1clBRh4ehpBgpCinTuB9CN UVSj6Wfcv3bDQqNgifbRNKFOMpnBdgA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1715363234; x=1746899234; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=1Bjsxi6FLuGOj7RtmewtKis8IikuC8YQFkIP8lxG5to=; b=kW7ZXFBY1KVlg9Brow+QjVkZHRPI+3P1TSrqtyYydsG4bPp7gL8krNUw WRIlsUgIuVMrtivHfV5jmwxhYsf66pR+jtV2fg+v36z6kV1hp8lEvajD9 DhDKTzjKwTgjkKRNHqexcDnOsqmjxw4J04OpY0pUY9bowgfZX05VcPh7T txSiFWyHhfVkduGwf8v8xFH78BLRn9G+bVt2Z726Eds1wrhcz2e3gLLMI gjMt1o+X0LuGLShw3sc5aWMdpfGHT/V0O+esTap53gvzEB5uEFySR12uL dlFeBLoXFOIFbzet2TFivBgESderVzooYD/YSH5/hLTymcR7Kn/w6VrMN g==; X-CSE-ConnectionGUID: ksgNOikdQ7SFo5sE6rpw6g== X-CSE-MsgGUID: kpPE6/FAR7+YmBkvIpEcIA== X-IronPort-AV: E=McAfee;i="6600,9927,11069"; a="22764915" X-IronPort-AV: E=Sophos;i="6.08,151,1712646000"; d="scan'208";a="22764915" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2024 10:47:02 -0700 X-CSE-ConnectionGUID: 9BuGuE57RSmgVyrAKM/GPQ== X-CSE-MsgGUID: qwl5bYPFRgeN0WD4/7PfJw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,151,1712646000"; d="scan'208";a="29540130" Received: from ls.sc.intel.com (HELO localhost) ([172.25.112.31]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2024 10:47:01 -0700 Date: Fri, 10 May 2024 10:47:00 -0700 From: Isaku Yamahata To: Sean Christopherson Cc: Michael Roth , Paolo Bonzini , 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, papaluri@amd.com, Isaku Yamahata , isaku.yamahata@linux.intel.com, rick.p.edgecombe@intel.com Subject: Re: [PATCH v15 21/23] KVM: MMU: Disable fast path for private memslots Message-ID: <20240510174700.GB480079@ls.amr.corp.intel.com> References: <20240501085210.2213060-1-michael.roth@amd.com> <20240510015822.503071-1-michael.roth@amd.com> <20240510152744.ejdy4jqawc2zd2dt@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 1DCBC140006 X-Stat-Signature: trmqt3r4s6jbb8hk6wpbx8d5d14xkqj9 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1715363233-333265 X-HE-Meta: U2FsdGVkX18B2bV1oNvTI5ROc4XCjGRMarlDMsXFb+1DZYa4rL7Dq1sLignL9l619aakY/9StExovlcHRHeHqYc891sCTIvUiUHr7g0nyIRzgTEEGSP4hAB1ZJFEFUobsAO/GrAu20kf6/KITsLdHJr6Lsvx35FawOmxl0K573z9GT6GwQYHdipZB/nl75S/MzsgPBXkL3ojMbBiQ+bg/NH0uvbmyuFELDnfRXzg/mKhHGCUtIsbRCPhSIKrQuOvNqZhUNyEQ0Wlz+GIgI/PbAl/glPazqLfJ9vUDFGubQakZcOARP9SKq0/Yr4lRnC1xqRoZsJcdVD//5SblcgPBWF/SBiUEMtjULvV+QnXWJeWJ/mTwGS89qdlZF5dMqL+IyRfcHTSvOkzOk43SQGXXe0p3ieIACd02y1QPB9QOcM/R2MSEvj9pK9Hfhz3RlDTpzZaIK87xFeXdx+xV9GpCUuGCbTR4Qy8v89COMr80i/OFyD/kQny0e7Cc18k1nLlJkZBjyQyIo9NiB6KEa3SLeDvDA/ngvgM6pduASEyhj2Qku7LHoJVvJmrLH8oAB6+n8l3ipBLbwWEKeH6pnYTLxGaeFtNzuHhuxDOM3rgASLMMQaD4yvtzUggIxXWWpsIp1U64uNKV+YOG/U6Vp6mCjGpmSKud75djUSBYFKOnyRr3UxYGEd1C0QNS/rntrbTjyLs/NGR69CJPseG7ypnedga7o1vouWKgoO5ZDBZRt38IGYqWVX7F92+0ta+G7pTSiHiL0Il5SY7VAUGc00H9CT9eX+xdOwtBxcWlY6vXcSmKoa8Ave7FKmaQW8uZoGQzZB/Gsy4VUrycCfYyADXTp6LofCNjb90EMBwMc/qNZpaNiiL1Dliepm3SXQMNPImj53W2Xjzz1ALNn7GY3ZJhjtQSekYXt+lOcW4uf9MqKaufLYktwjEu4fdA8Vejn34M3aBMwRuNStlAKmoPNG d9oWOteu gsxvOI0DnOZZzJrvY7m65eSEJlXCJS2wi05+/kGTWrA4z1NuZ2tZ/E5dj5fVoRwsyuoGB1ZE/AB+wQ7VYUKMBgPIBzfWYq23zLJ0Xm+GBVDyzdQHoZRaKAmfOinP4yBQvIZJOshcJvfrWlLAT6IEewBKm/9z90t2bOaDHBP2jQSpsqEdOm6KMYzYsTUuGDpS8+i+THg8RX8DboQcjtXDFjT4e9IkC8gciVTN2wmgVUkuE7J2CFnq4PQexu30tqXIUgN7Hp1bTUpbcRVPc2qh9fhQU+7xRVdXJiIturIu2KhkmAxY= 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 Fri, May 10, 2024 at 08:59:09AM -0700, Sean Christopherson wrote: > On Fri, May 10, 2024, Michael Roth wrote: > > On Fri, May 10, 2024 at 03:50:26PM +0200, Paolo Bonzini wrote: > > > On Fri, May 10, 2024 at 3:47 PM Sean Christopherson wrote: > > > > > > > > > + * Since software-protected VMs don't have a notion of a shared vs. > > > > > + * private that's separate from what KVM is tracking, the above > > > > > + * KVM_EXIT_MEMORY_FAULT condition wouldn't occur, so avoid the > > > > > + * special handling for that case for now. > > > > > > > > Very technically, it can occur if userspace _just_ modified the attributes. And > > > > as I've said multiple times, at least for now, I want to avoid special casing > > > > SW-protected VMs unless it is *absolutely* necessary, because their sole purpose > > > > is to allow testing flows that are impossible to excercise without SNP/TDX hardware. > > > > > > Yep, it is not like they have to be optimized. > > > > Ok, I thought there were maybe some future plans to use sw-protected VMs > > to get some added protections from userspace. But even then there'd > > probably still be extra considerations for how to handle access tracking > > so white-listing them probably isn't right anyway. > > > > I was also partly tempted to take this route because it would cover this > > TDX patch as well: > > > > https://lore.kernel.org/lkml/91c797997b57056224571e22362321a23947172f.1705965635.git.isaku.yamahata@intel.com/ > > Hmm, I'm pretty sure that patch is trying to fix the exact same issue you are > fixing, just in a less precise way. S-EPT entries only support RWX=0 and RWX=111b, > i.e. it should be impossible to have a write-fault to a present S-EPT entry. > > And if TDX is running afoul of this code: > > if (!fault->present) > return !kvm_ad_enabled(); > > then KVM should do the sane thing and require A/D support be enabled for TDX. > > And if it's something else entirely, that changelog has some explaining to do. Yes, it's for KVM_EXIT_MEMORY_FAULT case. Because Secure-EPT has non-present or all RWX allowed, fast page fault always returns RET_PF_INVALID by is_shadow_present_pte() check. I lightly tested the patch at [1] and it works for TDX KVM. [1] https://github.com/mdroth/linux/commit/39643f9f6da6265d39d633a703c53997985c1208 Just in case for that patch, Reviewed-by: Isaku Yamahata -- Isaku Yamahata