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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C5C0C433EF for ; Thu, 31 Mar 2022 01:02:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352214AbiCaBEE (ORCPT ); Wed, 30 Mar 2022 21:04:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346065AbiCaBEC (ORCPT ); Wed, 30 Mar 2022 21:04:02 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 885E165D31; Wed, 30 Mar 2022 18:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1648688536; x=1680224536; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=1dlEDgQKh23w/zXDxJY2KzGHeDnj9hNUwJGYdrUoU24=; b=O9FR3XY9HKZUsnbRXtOpPvfWryXx/4HX5AR2rz1o/xXol8pkRjIEM9pE eHkU4k2PiMCLERjW4shTRiIVMul79BU3DQZS92zs+iBnUe9/IDtzv7h6S 6NogvLY2Fh6C5N+06s6H/Iq18rvotBRWyEhH+BOURjOWeWwisLHevRrYJ rXJRefy1Sd2tiiDv8aVKkQuuX+/UpZlfmSwvLdJglnJtlY62g1YpxUu3h N+CXEH8JP6oxCWKvNW8Ew1yq/J1ysyvhYuM09mNJFP1UF/D0IMl5CQnr+ vWWomJXAIosUuNrZsrmhaBAbgeKG8AZ6sVOtSqotfkI3hpyYYfDfK/kPN g==; X-IronPort-AV: E=McAfee;i="6200,9189,10302"; a="259656694" X-IronPort-AV: E=Sophos;i="5.90,224,1643702400"; d="scan'208";a="259656694" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2022 18:02:15 -0700 X-IronPort-AV: E=Sophos;i="5.90,224,1643702400"; d="scan'208";a="554867541" Received: from dhathawa-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.254.53.226]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2022 18:02:13 -0700 Message-ID: Subject: Re: [RFC PATCH v5 008/104] KVM: TDX: Add a function to initialize TDX module From: Kai Huang To: Sean Christopherson , Isaku Yamahata Cc: Paolo Bonzini , isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson , erdemaktas@google.com, Connor Kuehl Date: Thu, 31 Mar 2022 14:02:11 +1300 In-Reply-To: References: <05aecc5a-e8d2-b357-3bf1-3d0cb247c28d@redhat.com> <20220314194513.GD1964605@ls.amr.corp.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org > > > > - VMXON on all pCPUs: The TDX module initialization requires to enable VMX > > (VMXON) on all present pCPUs. vmx_hardware_enable() which is called on creating > > guest does it. It naturally fits with the TDX module initialization at creating > > first TD. I wanted to avoid code to enable VMXON on loading the kvm_intel.ko. > > That's a solvable problem, though making it work without exporting hardware_enable_all() > could get messy. Could you elaborate a little bit on how to resolve? -- Thanks, -Kai