Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7055899rwb; Mon, 12 Dec 2022 09:29:28 -0800 (PST) X-Google-Smtp-Source: AA0mqf5PnBCwmruW1cJuUZL8KsBwqV+4wcoiLE0On2VyHsTrFPCQUq81rIevPzLU41jzVBnzOBkT X-Received: by 2002:a50:ec8d:0:b0:46c:a3c1:2057 with SMTP id e13-20020a50ec8d000000b0046ca3c12057mr14519405edr.29.1670866167786; Mon, 12 Dec 2022 09:29:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670866167; cv=none; d=google.com; s=arc-20160816; b=jMoNW+PIHQI3XR0a3wAYDuFo0CivZaZmwRzRMY9ADLLU8WxZcRyvUecyi9a+jWY9H/ E+ahUM1j98xZvggVCbysM/hE0FdHfvwza6xaYggDiZHGBPr+5Yy2E5woX0PgB1VCAve6 Hwzfj9dkc0we3EsL4uwF0L5h7mgEAOINkM+B5V+zpbXBlhrPx8MvpSkss2T7siKM/yKL 3CAGtTGrdo73EfySSIhz0tPWgxJERbffYKhikBsZTJPo3Z04ZWKg/jbMk2bzSDST2I4s bZLpj19NTaMnzpczY0IU+h4BhDknXWzujXE42j9Jos8b3o2AHxDbidZI07no1dqqKRWc Y/NA== 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=82ilGY2Sc8eIPQR3PFdaEbA/b67vNiUdai5P/R7Gxow=; b=UhLzKYIYTb6u+GkQetwaTN1laag8Y8LstU33GyxJeWp/p6R0bMmQRXGhDxl/Hhj0fC p9ECkg38nkK458l6MLsCpmlahCDvTBpZuCN4tqF0zMrsZXgf2XwwTMpZXvkrZ7Kgkt+q HmMLPb2KkO5bWd2PFb041hhZaQLj2MCxp7J/vfjxnN49QmI+V8/gsydXtnWqklRT2Utm BNhovfmt9Ile+Q5mJkE8fyi85ibs941FqyDXoS1IXj6AdwBIDbahzlV23ywdQFV1Q79T 9XujYMM2perQvJcnAz6zi9zh6rKJUDxyHyqugz7Vb5ykp88HzWj8ic2Phet6mhj69gNd W0fA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=g2H5xoQZ; 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 nd21-20020a170907629500b00778d193ca81si6547573ejc.550.2022.12.12.09.29.08; Mon, 12 Dec 2022 09:29:27 -0800 (PST) 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=g2H5xoQZ; 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 S232918AbiLLQkA (ORCPT + 74 others); Mon, 12 Dec 2022 11:40:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232884AbiLLQjL (ORCPT ); Mon, 12 Dec 2022 11:39:11 -0500 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED2FA165AC for ; Mon, 12 Dec 2022 08:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670863042; x=1702399042; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=9m98shoiHRD8thtXOIoPpIhyXXaG4Y2A8foSH8f3lII=; b=g2H5xoQZq90wK8V+efipKd8Uem/RMG0was2r9R3XPM4O0lVgDWRXncRg o/2NLwhnEn5+HiZLvQZVQcZr6Ngk1MAmd8VfNjeItUz0MCkVUPfO+vIeE cL56PZ421bhcjbp4fbhiwJ+YO6BbyKN9Bf8Gh3+pAmedyA8tPYUpDY6R3 4LtjTY37dcwjq7pZ6KyMX4J4KxvVTJ6A3H0Tx64E2oUBASOOBTZFXFnA4 g/ArM+nKlJ6SNMDi4GmKlhCOmsgDRgyqAo547pPq6VmCDOawcs2MCMqcC 62JR3qprMTPG88M/DoZ5wi0b9b1xpF1Vz9d9POunlr9i9lSoJoPPaFn6V A==; X-IronPort-AV: E=McAfee;i="6500,9779,10559"; a="317929849" X-IronPort-AV: E=Sophos;i="5.96,238,1665471600"; d="scan'208";a="317929849" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2022 08:37:10 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10559"; a="822545833" X-IronPort-AV: E=Sophos;i="5.96,238,1665471600"; d="scan'208";a="822545833" Received: from vasanth1-mobl.amr.corp.intel.com (HELO [10.251.4.160]) ([10.251.4.160]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2022 08:37:09 -0800 Message-ID: Date: Mon, 12 Dec 2022 08:37:09 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.2 Subject: Re: [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing SEPT_VE_DISABLE Content-Language: en-US To: Dave Hansen , "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Elena Reshetova , x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org References: <20221209132524.20200-1-kirill.shutemov@linux.intel.com> <20221209132524.20200-3-kirill.shutemov@linux.intel.com> <20221209170647.r32yjyc3hsqtnffo@box.shutemov.name> <2e305bb5-9595-3531-6134-24344ff5c797@linux.intel.com> From: Sathyanarayanan Kuppuswamy In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_HI, 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 12/12/22 8:10 AM, Dave Hansen wrote: > On 12/9/22 12:51, Sathyanarayanan Kuppuswamy wrote: >>>>> + while (1) { >>>>> + __tdx_hypercall(&args, 0); >>>>> + } >>>> Instead of an infinite loop, I'm wondering if the guest should panic after >>>> retrying for few times. >>> Hm. What difference would it make? >> IIUC, the goal of this patch is to report the fatal error to VMM and panic. >> But, if VMM does not terminate the guest as we expect, rather than trying >> continuously, isn't it better to panic ourselves? That way the behavior >> will be similar to what we have currently. > > What does "panic ourselves" mean exactly? What is the current behavior > which that would match? I meant directly calling panic(). Before this patch, if the SEPT VE DISABLE attribute was not set, we would call panic(). In this patch, we try to report the error to VMM and wait for it to terminate the guest in the same case. But after reporting the error, if VMM does not terminate the guest as expected, I thought instead of retrying continuously, we can call panic() directly after some retries. > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer