All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.