From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D441D2566 for ; Mon, 15 Jan 2024 06:22:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VgaT9AWs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1705299758; x=1736835758; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=GQIsLNn6hJVJTPHXRkaEq4wnPTcPIuPsr+uAqE0okVs=; b=VgaT9AWsfj/wFgYw6e4q95MVlQtmShgvIuYES4zSkOzcWJLbbdyd6wSM KLoenbrM8yuQxNLk9uPa991ShW+kc5h9iAWma+hS8B2n7Pw3GrFjpyKYU RT0M3sXkrm2LImBKlY9aAPUEzBp3QvPvmDdHoxOrYNddeONaBGIakIB7j UxH+TaaYOoMiabVSMv7H/fgBGHIjw99do85qASSHuDHeCaAkaAZKdUjLr tg++I5a6UutcsCv5Hftn776kti1sJTJkigDrwRs8EjOzCozJ51Rj441UJ vttXsqFDksT00b86kiqRWesgnLalC8Kl7DXP8cJExSTOBbIbDy3wPHBy6 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10953"; a="399220952" X-IronPort-AV: E=Sophos;i="6.04,195,1695711600"; d="scan'208";a="399220952" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2024 22:22:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10953"; a="733215325" X-IronPort-AV: E=Sophos;i="6.04,195,1695711600"; d="scan'208";a="733215325" Received: from liuzhao-optiplex-7080.sh.intel.com (HELO localhost) ([10.239.160.36]) by orsmga003.jf.intel.com with ESMTP; 14 Jan 2024 22:22:33 -0800 Date: Mon, 15 Jan 2024 14:35:31 +0800 From: Zhao Liu To: Xiaoyao Li Cc: Yuan Yao , Eduardo Habkost , Marcel Apfelbaum , "Michael S . Tsirkin" , Richard Henderson , Paolo Bonzini , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org, Zhenyu Wang , Zhuocheng Ding , Zhao Liu , Babu Moger , Yongwei Ma Subject: Re: [PATCH v7 08/16] i386: Expose module level in CPUID[0x1F] Message-ID: References: <20240108082727.420817-1-zhao1.liu@linux.intel.com> <20240108082727.420817-9-zhao1.liu@linux.intel.com> <20240115032524.44q5ygb25ieut44c@yy-desk-7060> <336a4816-966d-42b0-b34b-47be3e41446d@intel.com> <78168ef8-2354-483a-aa3b-9e184de65a72@intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78168ef8-2354-483a-aa3b-9e184de65a72@intel.com> On Mon, Jan 15, 2024 at 02:11:17PM +0800, Xiaoyao Li wrote: > Date: Mon, 15 Jan 2024 14:11:17 +0800 > From: Xiaoyao Li > Subject: Re: [PATCH v7 08/16] i386: Expose module level in CPUID[0x1F] > > On 1/15/2024 2:12 PM, Zhao Liu wrote: > > Hi Xiaoyao, > > > > On Mon, Jan 15, 2024 at 12:34:12PM +0800, Xiaoyao Li wrote: > > > Date: Mon, 15 Jan 2024 12:34:12 +0800 > > > From: Xiaoyao Li > > > Subject: Re: [PATCH v7 08/16] i386: Expose module level in CPUID[0x1F] > > > > > > > Yes, I think it's time to move to default 0x1f. > > > > > > we don't need to do so until it's necessary. > > > > Recent and future machines all support 0x1f, and at least SDM has > > emphasized the preferred use of 0x1f. > > The preference is the guideline for software e.g., OS. QEMU doesn't need to > emulate cpuid leaf 0x1f to guest if there is only smt and core level. Please, QEMU is emulating hardware not writing software. Is there any reason why we shouldn't emulate new and generic hardware behaviors and stick with the old ones? > because in this case, they are exactly the same in leaf 0xb and 0x1f. we don't > need to bother advertising the duplicate data. You can't "define" the same 0x0b and 0x1f as duplicates. SDM doesn't have such the definition. Regards, Zhao