Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp3998462rwe; Tue, 30 Aug 2022 02:47:14 -0700 (PDT) X-Google-Smtp-Source: AA6agR6PlviGAAdxeRqBuD3eNHlNIHm90W5jOVSiPmfx2JlRy8Ys94pkMpPOCo3VFsQq2Jg+cs0H X-Received: by 2002:a17:902:d50a:b0:174:3a33:3a6f with SMTP id b10-20020a170902d50a00b001743a333a6fmr19787734plg.119.1661852834334; Tue, 30 Aug 2022 02:47:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661852834; cv=none; d=google.com; s=arc-20160816; b=M4u+Wec3X6nUECGIg+ZkJTVc9UhcpSsQ/jtR69v8jaJ97tNW8Jkoz+jWwURK4/A4SQ LjJ8paxQcCN8b2Zkox1oSGS5V1TgwNT2fndVWym16cMa0K6V3+8UKb3SmbX2Frsibh9C eTmNHXshtcE3d6/TQqnEfAW6FMwbalqOXYYCTW+OIvdpQ6lXksoLqiL1teCMOBvy5u3b fOh1jYSawYfjnH1y/zRcUs29AY6K11ku5GOAQCtYjjazDXOYa9xgaK213JpqxKxBJrRl 57f1RsP6bUbALThubFyXC8dybRJtRMl8mPJNq3SVJ8yn8bUNxpUWmL39nN8HbSstmsDH 9jqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id :dkim-signature; bh=et09str4AduiDzJdMe9wBnLJVbmEW6WkJsbq8/Sgfus=; b=jqJm27ALnnCVPhrfncynP1q4Hs7M/we8jqnD9oJ/N7VudnfwCpswYANpD0LjCGEBMl eOhaQikZ32tuWscMRdCyp+t+AcuUicK49owtb93aCTm0wWJszwZwFxkTTQxJmhvG2g4y fGXAYk4jT7vg7KDdBj+T2/SuFNNbEt2yxiuCAY/G8zegrdJmjTTcPh31ABQAXjV2ykh6 NG8Y525ursnXcJIgyPXGZ2kNeP+Y4cg2V3z746+jlyLj1FNOJejnkIF9nP5WUEjA2QvC NBZPi7hH0FVqKOiHBD4oLrC+briGXeVG1Du5X/JO8zoaGPJqVFfPg5p2EN+cfe1l4IQm Q61Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YC5OvuaO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a23-20020a63e857000000b0041a77ebb731si1692016pgk.294.2022.08.30.02.47.04; Tue, 30 Aug 2022 02:47:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YC5OvuaO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231131AbiH3I5o (ORCPT + 99 others); Tue, 30 Aug 2022 04:57:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229697AbiH3I5h (ORCPT ); Tue, 30 Aug 2022 04:57:37 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1167D9FA82; Tue, 30 Aug 2022 01:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1661849854; x=1693385854; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=iFyqrBQdxTUBOpu9l4E3C3J/Crs7bTOiZ1ntimc+HSU=; b=YC5OvuaOapHHUl/e59sWdA1w8pUHbITorDwapbw2Xlfh6ao3GEGgtmWV nUe2r4xujjb3bTrcqSz776pNjX3c+IUMz2noVU3To/YguWPwE29GELYiJ Mc6+FVN7BspJ4flV9EKgfX4xkL0nPvwLM++zpCopLDGeN2saz/EyIAoC2 xI/D0Co3Qrh8hw9CyCt7aUiTOs4B/wKM1fiviKGimwOaI7/MOB7RC+rIS vO/pO1gA26Y/4Wf6jaOxwOCQQiywb+a1GIGmjiylTlniHy9/OGpbEIcK1 FSh92vCrxR79G1Qp4pMcAzOORFQeufKqQQprbwDOCnyrW4qGpR/zwW9Yn w==; X-IronPort-AV: E=McAfee;i="6500,9779,10454"; a="359086657" X-IronPort-AV: E=Sophos;i="5.93,274,1654585200"; d="scan'208";a="359086657" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2022 01:57:30 -0700 X-IronPort-AV: E=Sophos;i="5.93,274,1654585200"; d="scan'208";a="641290765" Received: from binbinwu-mobl.ccr.corp.intel.com (HELO [10.249.172.100]) ([10.249.172.100]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Aug 2022 01:57:27 -0700 Message-ID: <6704f880-14ed-b8e8-4204-ac0d8afef5ef@linux.intel.com> Date: Tue, 30 Aug 2022 16:57:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Subject: Re: [PATCH v8 020/103] KVM: TDX: create/destroy VM structure To: Isaku Yamahata Cc: isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , erdemaktas@google.com, Sean Christopherson , Sagi Shahar References: <810ce6dbd0330f06a80e05afa0a068b5f5b332f3.1659854790.git.isaku.yamahata@intel.com> <20220829190921.GA2700446@ls.amr.corp.intel.com> From: Binbin Wu In-Reply-To: <20220829190921.GA2700446@ls.amr.corp.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/8/30 3:09, Isaku Yamahata wrote: > >>> +} >>> + >>> +static int tdx_reclaim_page(unsigned long va, hpa_t pa, bool do_wb, u16 hkid) >>> +{ >>> + struct tdx_module_output out; >>> + u64 err; >>> + >>> + err = tdh_phymem_page_reclaim(pa, &out); >>> + if (WARN_ON_ONCE(err)) { >>> + pr_tdx_error(TDH_PHYMEM_PAGE_RECLAIM, err, &out); >>> + return -EIO; >>> + } >>> + >>> + if (do_wb) { >>> + err = tdh_phymem_page_wbinvd(set_hkid_to_hpa(pa, hkid)); >>> + if (WARN_ON_ONCE(err)) { >>> + pr_tdx_error(TDH_PHYMEM_PAGE_WBINVD, err, NULL); >>> + return -EIO; >>> + } >>> + } >>> + >>> + tdx_clear_page(va); >> Is it really necessary to clear the reclaimed page using MOVDIR64? >> >> According to the TDX module spec,  when add a page to TD, both for control >> structures and TD private memory, during the process some function of the >> TDX module will initialize the page using binding hkid and direct write >> (MOVDIR64B). >> >> So still need to clear the page using direct write to avoid integrity error >> when re-assign one page from old keyid to a new keyid as you mentioned in >> the comment? > Yes. As you described above, TDX module does when assining a page to a private > hkid. i.e. TDH.MEM.PAGE.{ADD, AUG}. But when re-assigning a page from an old > private hkid to a new _shared_ hkid, i.e. TDH.MEM.PAGE.REMOVE or > TDH.PHYMEM.PAGE.RECLAIM, TDX module doesn't. Is the reason you added the tdx_clear_page() here due to the description in 1.3.1 of Intel CPU Architectural Extensions Specification for TDX (343754-002US)? The description as following: "MKTME on an SOC that supports SEAM might support an integrity protected, memory encryption mode. When using keys with integrity enabled, the MKTME associates a message authentication code (MAC) with each cache line. By design, when reading a cache line using a KeyID with integrity enabled, if the MAC stored in the metadata does not match the MAC regenerated by the MKTME, then the cache line is marked poisoned to prevent the data from being consumed. Integrity protected memory must be initialized before being read, and such initialization must be performed using 64-bytes direct-store with 64-byte write atomicity using the MOVDIR64B instruction" Actually I have a question about the description,  does the initialization using MOVDIR64B must associated with the according hkid?