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 673BCC433EF for ; Wed, 13 Jul 2022 03:16:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230058AbiGMDQ5 (ORCPT ); Tue, 12 Jul 2022 23:16:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229888AbiGMDQy (ORCPT ); Tue, 12 Jul 2022 23:16:54 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF39AD7A6A; Tue, 12 Jul 2022 20:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657682212; x=1689218212; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=1Erh3CyyDV9THBc/EKhKsORANd2MPiX3UyCy+uJR4Fk=; b=XfEig+POze3uyqJz1NAyvnwxgLx6erNB/bca4PaSasEpAdfi9xhZa8Jt ycFd5sdZG1Afw3hfRtYsnlFwUwYx7I4hvB+S9UsKr+htOIOn9xD/fvfi3 HqtCSfHpyNeWCXrNMyrUAbMQ6Htel6g77H8EmAdYYMwGq7dhLUoDjTTzy I6MJq9nO6bQnywEKajRm6HGUfj3c0JfgMKu+l7LLtTiI56Ukusoij+BML inwF12oiFzde56pvlea2geAPgOPM6F48eq6FRfMRpho7OMMU87i2Af5Ih hQsrZ3EA/s9dYUedf/zDlHhIzx0Dt9CSMReWs+g/yygJgcPq2reqmrZ3B w==; X-IronPort-AV: E=McAfee;i="6400,9594,10406"; a="371411118" X-IronPort-AV: E=Sophos;i="5.92,266,1650956400"; d="scan'208";a="371411118" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2022 20:16:52 -0700 X-IronPort-AV: E=Sophos;i="5.92,266,1650956400"; d="scan'208";a="722194206" Received: from ifatima-mobl1.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.212.1.196]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2022 20:16:50 -0700 Message-ID: Subject: Re: [PATCH v7 003/102] KVM: Refactor CPU compatibility check on module initialiization From: Kai Huang To: isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: isaku.yamahata@gmail.com, Paolo Bonzini , Sean Christopherson Date: Wed, 13 Jul 2022 15:16:48 +1200 In-Reply-To: <1b5e06b237ad9f2bcbee320e95b94e336109b484.camel@intel.com> References: <1b5e06b237ad9f2bcbee320e95b94e336109b484.camel@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.3 (3.44.3-1.fc36) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > + /* hardware_enable_nolock() checks CPU compatibility on each CPUs. */ > > + r =3D hardware_enable_all(); > > + if (r) > > + goto out_free_2; > > + /* > > + * Arch specific initialization that requires to enable virtualizatio= n > > + * feature. e.g. TDX module initialization requires VMXON on all > > + * present CPUs. > > + */ > > + kvm_arch_post_hardware_enable_setup(opaque); >=20 > Please see my reply to your patch "KVM: TDX: Initialize TDX module when = loading > kvm_intel.ko". >=20 > The introduce of __weak kvm_arch_post_hardware_enable_setup() should be i= n that > patch since it has nothing to do the job you claimed to do in this patch. >=20 > And by removing it, this patch can be taken out of TDX series and upstrea= med > separately. I tried to dig more about the history. Please see my another reply and ign= ore this.