Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp1206578lqp; Fri, 22 Mar 2024 08:19:36 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWZWnLvXjnqjW73k+k83jc5qCYKGCWh0gUMMqpyEl2CDqqLVe0R54xWNYPr78rDDuPxS0ScDQrt1ME7a9wv87HgUi8EVejSPtPt+7mbMA== X-Google-Smtp-Source: AGHT+IH9nAwE/j4WTgJypqbT0HRfjQjnpCGr7fxhKus/Cl/SWf5NvNywCrVv6gYn3I00e2ljA8bp X-Received: by 2002:a05:620a:a98:b0:78a:32f2:ad7e with SMTP id v24-20020a05620a0a9800b0078a32f2ad7emr2927566qkg.56.1711120776631; Fri, 22 Mar 2024 08:19:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711120776; cv=pass; d=google.com; s=arc-20160816; b=QH9afi0Mfdwhy1wHRQchwHHNYY6bj/zdTYcinkhIIPrzzFom6HObIHHKktMCgpq8// aBxfcAW1WWfI+xzb5T578cgZdaonq5aBOu0/GFVqpUBAX/6BNb9oIm5c5fg0hcOXhZmR VOnFv/ZfeGQVZSCJ1T0c/x9CUs0k3cGNUiqvWkeMzC7pYPUAqYit0RNRe+MbGcqFWhvZ MppZVMKEsXBAeel3cP5pQRyzd65+XIcBpopf1cWU9ueLyjT1vUy0kPtcivwUVGrHnav6 SCiBXECi/c79O7FMmTC/wyVwBegPflKc0PGRQxAF9uwDlLBkEMLXYmmfu1FpLf/IyVjH bGVw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=8kvK+XksX+oEakbOLqgWpkAlFtCBPBf8MhIM8xrajPY=; fh=bFNvEww5pihKNeqRrSyZuvL50YIJcCtie2Q69aiTAMc=; b=eGSjhF5uogALbbnLo/Qjgxn8NWn2/RhW/WQOSJvvNTGu8VT4GTgzS5qqtE/9qTF8dD RD7VKtmHq2DJQRxZVJ5FBB/2ppcWEaEu0/GPzhS29QYA03HoEUUq+P3oWsPFLuwpWQE2 YAvugWRSl37GMzGj4mNm+AutbwuTEgO3FhcmfRYm3ZZGDU9VkZlXMSTWEHLOElwn/0Pv a23IyBe9WvzfnHmh6zPaUlxzpuKKxRtZ/6hGu07aHSZuKm5KEszlpZe8/KhhXv99YT3z 5f1OWLHLMFiK+wjAyzyF/oJFR6vqPVXBW5tV0AeKmNeswR+ZFact+zFRHFSxHVXntx3D q5iQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FCVGPm17; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-111692-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-111692-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id x21-20020ae9e915000000b00789e9aa2d1bsi2012415qkf.508.2024.03.22.08.19.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Mar 2024 08:19:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-111692-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FCVGPm17; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-111692-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-111692-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 55A1D1C20C5D for ; Fri, 22 Mar 2024 15:19:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 659174E1DD; Fri, 22 Mar 2024 15:19:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="FCVGPm17" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F08545BE4; Fri, 22 Mar 2024 15:19:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711120767; cv=none; b=GwkzQ5UPeEZicd7m6X9wfmNNSt99FY7p7NepJqO8e3xwCAh+rxAZBpbSIf6cPQ8w0viF0VvPl+d5VMkX7NUeaqs3EVolHksZnzNwGamfgQLw5da2SK5nIaGSg5OLU9IiczSsa1lFIoA4pVKRJlD3Mw8deWI49zfDes+PzO1zGqI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711120767; c=relaxed/simple; bh=EmauFkFzSgc/qDZcww6tdS37MuHANiCdzNtCEy1AVn0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=e5jlvprQKumPhA/Kgd+9efW5AElCAwFJnVG+AHGadPgNB15PcPHV6iIiZ8Vu8CCFzjOWPVo0iDxcfo6HB8HPvP1vuSQpwtEBlZyBTOWzpVr4R1YtV3NGEuq3fbTK9wreAlkqnD4j2uvZzHxUk5kb6Y7zk1OFPckioG2bE6y2OFM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=FCVGPm17; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711120765; x=1742656765; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=EmauFkFzSgc/qDZcww6tdS37MuHANiCdzNtCEy1AVn0=; b=FCVGPm17XL3MhKWPPtccQYru53bUjbRvZtUL1U+SeFthCgUOXwRvZoxs FuwEOkNRxAEPVzXAFz3AkqmnUVRF1C9o8E7EpJhdca1frjSrhNEbsMPWe ScXXEdbsQuoboMXIuSVkfW0E1AGdPbJwl/C7yy/eQi+drRC5BbXMW3eXe f4AQcz2w+iZjGzALl/wFmU3nKll3KXF1tr7ProzTDhllOHwNjCBCEJSYr wlDCwESaqagE5lQCglnkNSFAkimsCrOaO3KBQp9v8Uqu2LYvoySFrHovM kzCqX/bZAnAaxlSv+MWph01srOxvQJTaoEgHn2zbIA/kxvv7Njqw8a7x5 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11020"; a="6359140" X-IronPort-AV: E=Sophos;i="6.07,146,1708416000"; d="scan'208";a="6359140" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2024 08:19:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,146,1708416000"; d="scan'208";a="19636008" Received: from ls.sc.intel.com (HELO localhost) ([172.25.112.31]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2024 08:19:24 -0700 Date: Fri, 22 Mar 2024 08:19:23 -0700 From: Isaku Yamahata To: Chao Gao Cc: Isaku Yamahata , "Edgecombe, Rick P" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Zhang, Tina" , "seanjc@google.com" , "Yuan, Hang" , "Huang, Kai" , "Chen, Bo2" , "sagis@google.com" , "isaku.yamahata@gmail.com" , "Aktas, Erdem" , "pbonzini@redhat.com" , isaku.yamahata@linux.intel.com Subject: Re: [PATCH v19 056/130] KVM: x86/tdp_mmu: Init role member of struct kvm_mmu_page at allocation Message-ID: <20240322151923.GX1994522@ls.amr.corp.intel.com> References: <5d2307efb227b927cc9fa3e18787fde8e1cb13e2.1708933498.git.isaku.yamahata@intel.com> <9c58ad553facc17296019a8dad6a262bbf1118bd.camel@intel.com> <20240321212412.GR1994522@ls.amr.corp.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Mar 22, 2024 at 03:18:39PM +0800, Chao Gao wrote: > On Thu, Mar 21, 2024 at 02:24:12PM -0700, Isaku Yamahata wrote: > >On Thu, Mar 21, 2024 at 12:11:11AM +0000, > >"Edgecombe, Rick P" wrote: > > > >> On Mon, 2024-02-26 at 00:25 -0800, isaku.yamahata@intel.com wrote: > >> > To handle private page tables, argument of is_private needs to be > >> > passed > >> > down.  Given that already page level is passed down, it would be > >> > cumbersome > >> > to add one more parameter about sp. Instead replace the level > >> > argument with > >> > union kvm_mmu_page_role.  Thus the number of argument won't be > >> > increased > >> > and more info about sp can be passed down. > >> > > >> > For private sp, secure page table will be also allocated in addition > >> > to > >> > struct kvm_mmu_page and page table (spt member).  The allocation > >> > functions > >> > (tdp_mmu_alloc_sp() and __tdp_mmu_alloc_sp_for_split()) need to know > >> > if the > >> > allocation is for the conventional page table or private page table.  > >> > Pass > >> > union kvm_mmu_role to those functions and initialize role member of > >> > struct > >> > kvm_mmu_page. > >> > >> tdp_mmu_alloc_sp() is only called in two places. One for the root, and > >> one for the mid-level tables. > >> > >> In later patches when the kvm_mmu_alloc_private_spt() part is added, > >> the root case doesn't need anything done. So the code has to take > >> special care in tdp_mmu_alloc_sp() to avoid doing anything for the > >> root. > >> > >> It only needs to do the special private spt allocation in non-root > >> case. If we open code that case, I think maybe we could drop this > >> patch, like the below. > >> > >> The benefits are to drop this patch (which looks to already be part of > >> Paolo's series), and simplify "KVM: x86/mmu: Add a private pointer to > >> struct kvm_mmu_page". I'm not sure though, what do you think? Only > >> build tested. > > > >Makes sense. Until v18, it had config to disable private mmu part at > >compile time. Those functions have #ifdef in mmu_internal.h. v19 > >dropped the config for the feedback. > > https://lore.kernel.org/kvm/Zcrarct88veirZx7@google.com/ > > > >After looking at mmu_internal.h, I think the following three function could be > >open coded. > >kvm_mmu_private_spt(), kvm_mmu_init_private_spt(), kvm_mmu_alloc_private_spt(), > >and kvm_mmu_free_private_spt(). > > It took me a few minutes to figure out why the mirror root page doesn't need > a private_spt. > > Per TDX module spec: > > Secure EPT’s root page (EPML4 or EPML5, depending on whether the host VMM uses > 4-level or 5-level EPT) does not need to be explicitly added. It is created > during TD initialization (TDH.MNG.INIT) and is stored as part of TDCS. > > I suggest adding the above as a comment somewhere even if we decide to open-code > kvm_mmu_alloc_private_spt(). 058/130 has such comment. The citation from the spec would be better. > IMO, some TDX details bleed into KVM MMU regardless of whether we open-code > kvm_mmu_alloc_private_spt() or not. This isn't good though I cannot think of > a better solution. > -- Isaku Yamahata