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 BF500C48BCD for ; Wed, 9 Jun 2021 21:42:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A1310613EE for ; Wed, 9 Jun 2021 21:42:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229740AbhFIVoh (ORCPT ); Wed, 9 Jun 2021 17:44:37 -0400 Received: from mga11.intel.com ([192.55.52.93]:60077 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229517AbhFIVof (ORCPT ); Wed, 9 Jun 2021 17:44:35 -0400 IronPort-SDR: ykykX7IhucxrJmkwCZ1qFC+TUKKZfEKh0QcIRPAUZuzjkzRX7voEGYc3MEDG/6AbhrIMmoWMeg hvsTgnCvkNCg== X-IronPort-AV: E=McAfee;i="6200,9189,10010"; a="202150765" X-IronPort-AV: E=Sophos;i="5.83,261,1616482800"; d="scan'208";a="202150765" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2021 14:42:40 -0700 IronPort-SDR: 8lJ90QieKXiF2nbXI6rgmJp7jaYGkh6iProettwo8D0QW/OZGUiG7AnZpqIEB4lekubnI6zmHn Vcvq3MyAXtyw== X-IronPort-AV: E=Sophos;i="5.83,261,1616482800"; d="scan'208";a="402579860" Received: from davidhok-mobl3.amr.corp.intel.com (HELO skuppusw-mobl5.amr.corp.intel.com) ([10.209.9.9]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2021 14:42:39 -0700 Subject: Re: [RFC v2-fix-v5 1/1] x86: Skip WBINVD instruction for VM guest To: Dan Williams , Dave Hansen Cc: Peter Zijlstra , Andy Lutomirski , Tony Luck , Andi Kleen , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Raj Ashok , Sean Christopherson , Linux Kernel Mailing List References: <973add45-9fd2-7abc-3a97-96a26c263ea0@linux.intel.com> <20210609194926.1949859-1-sathyanarayanan.kuppuswamy@linux.intel.com> <7c06b567-9a65-8c7c-6046-3dcb32d4bb15@intel.com> From: "Kuppuswamy, Sathyanarayanan" Message-ID: <2184400d-856e-ed4c-b23d-77b7dfd72658@linux.intel.com> Date: Wed, 9 Jun 2021 14:42:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/9/21 2:38 PM, Dan Williams wrote: >> In TDX guests, these WBINVD operations cause #VE exceptions. For debug, >> it would be ideal for the #VE handler to be able to WARN() when an >> unexpected WBINVD occurs. (<--- problem #2) > ...but it doesn't WARN() it triggers unhandled #VE, unless I missed > another patch that precedes this that turns it into a WARN()? If a > code path expects WBINVD for correct operation and the guest can't > execute that sounds fatal, not a WARN to me. Yes. It is not WARN. It is a fatal unhandled exception. > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer