qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Zhao Liu <zhao1.liu@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, Dongli Zhang <dongli.zhang@oracle.com>
Subject: Re: [PATCH 0/2] i386: Adjust CPUID_EXT_PDCM based on enable_pmu at realization
Date: Fri, 7 Mar 2025 00:51:08 +0800	[thread overview]
Message-ID: <84abfe3b-babd-41de-b527-dc9644bcff4e@intel.com> (raw)
In-Reply-To: <Z8nL0eLE/trEtlNd@intel.com>

On 3/7/2025 12:22 AM, Zhao Liu wrote:
> Hi Xiaoyao,
> 
>> First, it's not a good practice that values in env->features[] cannot be
>> directly used for guest CPUID in void cpu_x86_cpuid(), but require further
>> adjustment there. env->features[] are supposed to be finalized at cpu
>> realization, so that after it env->features[] is reliable.
>>
>> Second, there is one dependency entry relates to CPUID_EXT_PDCM in
>> feature_dependencies[]. QEMU needs to get correct value of
>> CPUID_EXT_PDCM in env->features[] to ensure applying the dependencies
>> correctly.
> 
> I agree that this is a very good idea, especially since PDCM has a
> dependency entry.
> 
> "pmu" is totally a property rather than a feature bit, which makes the
> dependency relationships in the code complex. Therefore, I think it's
> worth having a series to clarify the dependencies of pmu as much as
> possible.
> 
> I remember Dapeng/Zide also have fixes for pmu dependencies, and if
> possible, I could help you combine this series with others' cleanups.

The reason I sent out this small series quickly is mainly for Dongli to 
as a reference.

In fact, there are mess on LBR enabling that it checks enable_pmu 
everytime with CPUID_7_0_EDX_ARCH_LBR as well as 
CPUID_8000_0022_EAX_PERFMON_V2. That's on my WIP list to clean it up.

I think I need to check if they are duplicated with Dapeng/Zide's series.

> Additionally, I think patch 1 and patch 2 can be merged together. Do you
> agree?

IMHO, they stand as their own. I'll leave it to Paolo to make the decision.

> Thanks,
> Zhao
> 



  reply	other threads:[~2025-03-06 16:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04  5:24 [PATCH 0/2] i386: Adjust CPUID_EXT_PDCM based on enable_pmu at realization Xiaoyao Li
2025-03-04  5:24 ` [PATCH 1/2] i386/cpu: Move adjustment of CPUID_EXT_PDCM before feature_dependencies[] check Xiaoyao Li
2025-03-06 15:52   ` Zhao Liu
2025-03-04  5:24 ` [PATCH 2/2] i386/cpu: Warn about why CPUID_EXT_PDCM is not available Xiaoyao Li
2025-03-06 15:52   ` Zhao Liu
2025-03-06 16:22 ` [PATCH 0/2] i386: Adjust CPUID_EXT_PDCM based on enable_pmu at realization Zhao Liu
2025-03-06 16:51   ` Xiaoyao Li [this message]
2025-06-17 18:01 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84abfe3b-babd-41de-b527-dc9644bcff4e@intel.com \
    --to=xiaoyao.li@intel.com \
    --cc=dongli.zhang@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zhao1.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).