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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 162CDC433B4 for ; Tue, 18 May 2021 15:46:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ECF5E611BF for ; Tue, 18 May 2021 15:46:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350397AbhERPsJ (ORCPT ); Tue, 18 May 2021 11:48:09 -0400 Received: from mga05.intel.com ([192.55.52.43]:39725 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350318AbhERPq7 (ORCPT ); Tue, 18 May 2021 11:46:59 -0400 IronPort-SDR: W+3ucHEq/3pSbifLHjail9pJ2xUNz9R3IlgAITLKVxxnZjP+hoVPhGsN+FAE6F8dJIfjDI9u/y 54UUwRX2JyeQ== X-IronPort-AV: E=McAfee;i="6200,9189,9988"; a="286276347" X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="286276347" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 08:45:11 -0700 IronPort-SDR: J9dsPtbby4SXKSNBWfssLgT5WjxAbZ3aGBDqhM9LswFO5Fi103DeP9fWngToYkEB+1kjRSKFC0 ARYWrU7NxepA== X-IronPort-AV: E=Sophos;i="5.82,310,1613462400"; d="scan'208";a="439495053" Received: from msaber-mobl.amr.corp.intel.com (HELO [10.209.65.183]) ([10.209.65.183]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 08:45:11 -0700 Subject: Re: [RFC v2-fix 1/1] x86/traps: Add #VE support for TDX guest To: Dave Hansen , Kuppuswamy Sathyanarayanan , Peter Zijlstra , Andy Lutomirski Cc: Tony Luck , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Dan Williams , Raj Ashok , Sean Christopherson , linux-kernel@vger.kernel.org, Sean Christopherson References: <20210518000957.257869-1-sathyanarayanan.kuppuswamy@linux.intel.com> <4fc32900-412d-fa10-520e-afa6caade33e@intel.com> From: Andi Kleen Message-ID: <81c0f447-44b8-c2b6-ce41-a39ec0a1832b@linux.intel.com> Date: Tue, 18 May 2021 08:45:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <4fc32900-412d-fa10-520e-afa6caade33e@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/18/2021 8:11 AM, Dave Hansen wrote: > On 5/17/21 5:09 PM, Kuppuswamy Sathyanarayanan wrote: >> After TDGETVEINFO #VE could happen in theory (e.g. through an NMI), >> although we don't expect it to happen because we don't expect NMIs to >> trigger #VEs. Another case where they could happen is if the #VE >> exception panics, but in this case there are no guarantees on anything >> anyways. > This implies: "we do not expect any NMI to do MMIO". Is that true? Why? Only drivers that are not supported in TDX anyways could do it (mainly watchdog drivers) panic is an exception, but that has been already covered. -Andi