All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Zide Chen <zide.chen@intel.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Zhao Liu <zhao1.liu@intel.com>, Peter Xu <peterx@redhat.com>,
	Fabiano Rosas <farosas@suse.de>
Cc: xiaoyao.li@intel.com, Dongli Zhang <dongli.zhang@oracle.com>
Subject: Re: [PATCH 6/7] target/i386: Make some PEBS features user-visible
Date: Mon, 19 Jan 2026 11:30:39 +0800	[thread overview]
Message-ID: <56dd6056-e3e2-46cd-9426-87c7889bed49@linux.intel.com> (raw)
In-Reply-To: <20260117011053.80723-7-zide.chen@intel.com>


On 1/17/2026 9:10 AM, Zide Chen wrote:
> Populate selected PEBS feature names in FEAT_PERF_CAPABILITIES to make
> the corresponding bits user-visible CPU feature knobs, allowing them to
> be explicitly enabled or disabled via -cpu +/-<feature>.
>
> Once named, these bits become part of the guest CPU configuration
> contract.  If a VM is configured with such a feature enabled, migration
> to a destination that does not support the feature may fail, as the
> destination cannot honor the guest-visible CPU model.
>
> The PEBS_FMT bits are intentionally not exposed. They are not meaningful
> as user-visible features, and QEMU registers CPU features as boolean
> QOM properties, which makes them unsuitable for representing and
> checking numeric capabilities.

Currently KVM supports user space sets PEBS_FMT (see vmx_set_msr()), but
just requires the guest PEBS_FMT is identical with host PEBS_FMT.

IIRC, many places in KVM judges whether guest PEBS is enabled by checking
the guest PEBS_FMT. If we don't expose PEBS_FMT to user space, how does KVM
get the guest PEBS_FMT?


>
> Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> Signed-off-by: Zide Chen <zide.chen@intel.com>
> ---
>  target/i386/cpu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index f1ac98970d3e..fc6a64287415 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -1618,10 +1618,10 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
>          .type = MSR_FEATURE_WORD,
>          .feat_names = {
>              NULL, NULL, NULL, NULL,
> +            NULL, NULL, "pebs-trap", "pebs-arch-reg"
>              NULL, NULL, NULL, NULL,
> -            NULL, NULL, NULL, NULL,
> -            NULL, "full-width-write", NULL, NULL,
> -            NULL, NULL, NULL, NULL,
> +            NULL, "full-width-write", "pebs-baseline", NULL,
> +            NULL, "pebs-timing-info", NULL, NULL,
>              NULL, NULL, NULL, NULL,
>              NULL, NULL, NULL, NULL,
>              NULL, NULL, NULL, NULL,

  reply	other threads:[~2026-01-19  3:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-17  1:10 [PATCH 0/7] target/i386: Misc PMU, PEBS, and MSR fixes and improvements Zide Chen
2026-01-17  1:10 ` [PATCH 1/7] target/i386: Disable unsupported BTS for guest Zide Chen
2026-01-19  1:47   ` Mi, Dapeng
2026-01-20 18:09     ` Chen, Zide
2026-01-17  1:10 ` [PATCH 2/7] target/i386: Don't save/restore PERF_GLOBAL_OVF_CTRL MSR Zide Chen
2026-01-17  1:10 ` [PATCH 3/7] target/i386: Gate enable_pmu on kvm_enabled() Zide Chen
2026-01-19  2:02   ` Mi, Dapeng
2026-01-17  1:10 ` [PATCH 4/7] target/i386: Support full-width writes for perf counters Zide Chen
2026-01-19  3:11   ` Mi, Dapeng
2026-01-17  1:10 ` [PATCH 5/7] target/i386: Save/Restore DS based PEBS specfic MSRs Zide Chen
2026-01-17  1:10 ` [PATCH 6/7] target/i386: Make some PEBS features user-visible Zide Chen
2026-01-19  3:30   ` Mi, Dapeng [this message]
2026-01-20 21:58     ` Chen, Zide
2026-01-21  5:19       ` Mi, Dapeng
2026-01-25  8:38       ` Zhao Liu
2026-01-27  0:51         ` Chen, Zide
2026-01-17  1:10 ` [PATCH 7/7] target/i386: Increase MSR_BUF_SIZE and split KVM_[GET/SET]_MSRS calls Zide Chen

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=56dd6056-e3e2-46cd-9426-87c7889bed49@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=dongli.zhang@oracle.com \
    --cc=farosas@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=xiaoyao.li@intel.com \
    --cc=zhao1.liu@intel.com \
    --cc=zide.chen@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.