Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp803587rwi; Mon, 31 Oct 2022 07:45:56 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4ToG4Eb6TRITi16ywN14UXzMQVMTIOdnwMJmrkyXb4cNJr6uvwdTKPMaUvtGDRBjZpdhS8 X-Received: by 2002:a63:814a:0:b0:460:9025:6e4a with SMTP id t71-20020a63814a000000b0046090256e4amr13220978pgd.135.1667227555952; Mon, 31 Oct 2022 07:45:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667227555; cv=none; d=google.com; s=arc-20160816; b=jtfecoKvHpdQrLemJ19H+dX3EUrujsUMxqF1VxYLRnW8Chow48B5lwVSpnYnjsmJ3P H4Jp8fxHzJjWnCI6P991NgqNBdGsGC/0XZ+BjQG5P1lFrG+aL0xim/MoEwIxmb7CRBxF axIf0Jgfbl/peNI7tn5EJLZ98Ku/v1kVErGJnIon7r4i7+b1tb5bIzBZBu86Vplc+AVQ 567exPmS0AAD9vfbv8XbklytRXJTU/WPqXMzx+I5gZqUf7w50d7dFPiqjo9mjC0cuPDG E8J7OgbSke7MiOmbc1LgSoAVzLFXd6m1xrrpgg356NOmtaPMrOwDJEi+9pS+vKKZ0yv6 m+oA== 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:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=casHSWpI0OWOsJ1D5bUA5X1VKxRi7q0vRjnI8+oWHqg=; b=kYzqHMvHIY0vLYAN3LD23eaWigM/PfA/nma4wKtZBGCf4ems7kOyI0g8LBcaA3QWnO uZv7ABIISNPx9cUGaZLq0pz+U8K/m6ZmBmzhW6weAVcVB0NRlJa1C4C7NugEaf9QXLvJ JENpp9j4GD494eSPH7p9h9NeC3Nt6WImohnrrbrMxERPweelgrG2I5cwI0zhhsun06lM LUvHVV6Ez2EMw3M09MXdKxra3ICn1jLx2mlZlSVMDi+KHud+T4UGqC/zFrBjwIjLeF3b TkJaUm+OuvHBcTVcZ5aIs0E3Iz5/UVZ9Yyota8slkZdNylNPcxAzUdwOSxs8FL0YhXEV RFpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=k4oJTPGz; 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 n16-20020a170902f61000b001868bb70fd5si9383000plg.124.2022.10.31.07.45.42; Mon, 31 Oct 2022 07:45:55 -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=k4oJTPGz; 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 S231537AbiJaOWn (ORCPT + 99 others); Mon, 31 Oct 2022 10:22:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231534AbiJaOWl (ORCPT ); Mon, 31 Oct 2022 10:22:41 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED49525C9 for ; Mon, 31 Oct 2022 07:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667226159; x=1698762159; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=jLXu6gq3vGZxJtvk5qii7PRMYQi6nR4c8aoYP5o3ZPE=; b=k4oJTPGzanq4pMIfUPWttqDpk7Oa+hj7l2xTR9or2SjW5ApFz8vIifyh hoM7XE6Acl9SEokB1C71SCZxV7Jvd6Dgw51HOY/N2R1WlQWmvj4506dac pGv8mcaueDAwQZOvXHS46mYxTps+e3Cc/Oh1NWR4QwBY6Q8ti/GuHqaPL UXrq0zuVmQ807HvzCorFUdTkG6xqA2w/3VzTiMQ1BSPA0xkn7JBU5Tw6d Ot37X4RA9UfC4OoRb/lbfVPB05nJmfgjHnow1TsmdXhUWstnk9Fydky2F aIiJVAVir6y9dQvao1Q58+0kRa+WzF1IVWZbreAm2x/SJm16+k4tC3vIv Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10517"; a="296322924" X-IronPort-AV: E=Sophos;i="5.95,228,1661842800"; d="scan'208";a="296322924" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Oct 2022 07:22:39 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10517"; a="722823180" X-IronPort-AV: E=Sophos;i="5.95,228,1661842800"; d="scan'208";a="722823180" Received: from jfbondi-mobl1.amr.corp.intel.com (HELO [10.212.163.129]) ([10.212.163.129]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Oct 2022 07:22:38 -0700 Message-ID: <4bfcd256-b926-9b1c-601c-efcff0d16605@intel.com> Date: Mon, 31 Oct 2022 07:22:36 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH 2/2] x86/tdx: Do not allow #VE due to EPT violation on the private memory Content-Language: en-US To: Guorui Yu , kirill.shutemov@linux.intel.com Cc: ak@linux.intel.com, bp@alien8.de, dan.j.williams@intel.com, david@redhat.com, elena.reshetova@intel.com, hpa@zytor.com, linux-kernel@vger.kernel.org, luto@kernel.org, mingo@redhat.com, peterz@infradead.org, sathyanarayanan.kuppuswamy@linux.intel.com, seanjc@google.com, tglx@linutronix.de, thomas.lendacky@amd.com, x86@kernel.org References: <20221028141220.29217-3-kirill.shutemov@linux.intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_NONE 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 10/30/22 21:07, Guorui Yu wrote: > We have encountered similar problems on SEV-ES, here are their fixes > on Kernel [1] and OVMF[2]. SEV-ES and TDX are very different beasts in this area. > Instead of enforcing the ATTR_SEPT_VE_DISABLE in TDX guest kernel, I > think the fix should also include necessary check on the MMIO path of > the #VE routine. Instead? Without ATTR_SEPT_VE_DISABLE, a #VE can occur on basically any instruction. We call those kinds of exceptions "paranoid entry" points. They need special handling like the NMI or #MC handlers. I'd be happy to look at a patch that does the MMIO path check *and* turns the #VE handler into a robust entry point. Bonus points if you can do ~5 lines of C like the approach in this thread.