Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp6570rwd; Wed, 7 Jun 2023 18:15:43 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4W1EbCXKT8u2DKDowbxVwC/NE2+199xFWWMRz9q+sEWBeY+JeNKCqZb8EQzg/eZ5naRIW5 X-Received: by 2002:a17:90a:6887:b0:24d:ee34:57b6 with SMTP id a7-20020a17090a688700b0024dee3457b6mr3386353pjd.41.1686186942998; Wed, 07 Jun 2023 18:15:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686186942; cv=none; d=google.com; s=arc-20160816; b=Jh/WI6GocLf0oPWV6kVVQjuHI6IjEiSetU/LjylKfFxMwflfspn/HEGdCIdAjRXyuu d+D/iRvyZP4vlMk0Nt1rfqlUBHBta8TMh0ENc5f2UK8eYhXLotA8oWbX9pv+6zwhfdg0 Z31YqZ8LJgGgT+unsktPz1FaeiyI4HWjjKNl7VpRhidfnUL/1DBYh6NlnNqNApfzkGea P5wsMvJ03ckwLUqBAZ41NurRD29aV2ug4jOri/SMig3MOhxj+RCX93ul1y9i/+Y6odkX dZzdauFgkf3eF8lJip4q9BMQ3vMsj5T2mOzwLC+uYSfeH2LqPgXw0K5wLg3p+nTEbbF1 rp4g== 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=I1A1VanUNhygxiE/XhqW67wsXl3/PbqKrU7k0TghbD4=; b=QTMFTIbh0EprKiragf02dwY2tJr5K6ALe+qPWuI0kobxYyxEHYPXVXjK1xnMIyCfL2 vXFROg6N6RnIKfKuISzF/081kR4tXNm3SYFTCePzzsoe+3EJsejI2ewUUcgUYgD0ruBo OiGlVUalsxUoJ0BDP0RqTR/G3qYgtSPEzR9uRCX4G/vhE7WwfQt+Jr/UwAj9rssmGhMA Y+85gkzgi19TKd5jlZT/x0EgfBQdlgxpBAoezXH5ppSaxRW4e2WZE9X+mfnSoJe+/riE pr3h2yBuuXJ0KxeDyUbWWRF8/vExKg/vHmLEUBkiumq4lduo5vYVbD1/kjj7+gVTkDre iRoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="T/IPP0C5"; 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 z9-20020a17090a8b8900b002535fa552f2si1880798pjn.85.2023.06.07.18.15.30; Wed, 07 Jun 2023 18:15:42 -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="T/IPP0C5"; 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 S232539AbjFHAaA (ORCPT + 99 others); Wed, 7 Jun 2023 20:30:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230479AbjFHA36 (ORCPT ); Wed, 7 Jun 2023 20:29:58 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DEA802128; Wed, 7 Jun 2023 17:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686184197; x=1717720197; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=TDhH3H4jg2X/8d8NcY3cf7ZRv9oNiNqThvaMDhA7KtI=; b=T/IPP0C51J8+9miklCFM5xoA+7PBkeTPx/gZ6CXT3PsqVDIbEQNZnDGU CPUn/djcfArAQwMN180UsMne1825xjLcvX6xzXs9da+eyaBpM9IhjHW77 ROxd2n8RhenjUWrITst3HDbfRaFX5FStExMCZc6m6gJIJ9Fqsl7zMq71w bblauOzvYdhKsUvlWGOAD0wct3DZSR0uwvrWJQTeFIGI26OBVUmURKNGA S8yfhSXgH98dtEw/FSjvNTEytslbWNX7UdGoDP4FRzrxeCVGUEo2cS4+9 R3ASTgnB94Sqs44KcruAFpbwtQAap3281V0Vc1nQg4sXOFGkkKB+6vNvk w==; X-IronPort-AV: E=McAfee;i="6600,9927,10734"; a="346762802" X-IronPort-AV: E=Sophos;i="6.00,225,1681196400"; d="scan'208";a="346762802" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2023 17:29:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10734"; a="779664634" X-IronPort-AV: E=Sophos;i="6.00,225,1681196400"; d="scan'208";a="779664634" Received: from vsmyers-mobl2.amr.corp.intel.com (HELO [10.212.146.233]) ([10.212.146.233]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2023 17:29:56 -0700 Message-ID: Date: Wed, 7 Jun 2023 17:29:55 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v11 06/20] x86/virt/tdx: Handle SEAMCALL running out of entropy error Content-Language: en-US To: "Huang, Kai" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "Luck, Tony" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Chatre, Reinette" , "Christopherson,, Sean" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "Yamahata, Isaku" , "linux-mm@kvack.org" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <9b3582c9f3a81ae68b32d9997fcd20baecb63b9b.1685887183.git.kai.huang@intel.com> <1e58e3df-ae9a-607c-cfc3-4f3d033ed531@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 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,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 6/7/23 16:36, Huang, Kai wrote: > On Wed, 2023-06-07 at 08:08 -0700, Hansen, Dave wrote: >> On 6/4/23 07:27, Kai Huang wrote: >>> Certain SEAMCALL leaf functions may return error due to running out of >>> entropy, in which case the SEAMCALL should be retried as suggested by >>> the TDX spec. >>> >>> Handle this case in SEAMCALL common function. Mimic the existing >>> rdrand_long() to retry RDRAND_RETRY_LOOPS times. >> >> ... because who are we kidding? When the TDX module says it doesn't >> have enough entropy it means rdrand. > > The TDX spec says "e.g., RDRAND or RDSEED". Let's just say something a bit more useful and ambiguous: Some SEAMCALLs use the RDRAND hardware and can fail for the same reasons as RDRAND. Use the kernel RDRAND retry logic for them. We don't need to say "RDRAND and RDSEED", just saying "RDRAND hardware" is fine. Everybody knows what you mean.