Re: [PATCH 6/7] target/i386: Make some PEBS features user-visible

[Zhao Liu <zhao1.liu@intel.com>]

Hi Zide & Dapeng,

> On 1/18/2026 7:30 PM, Mi, Dapeng wrote:
> > 
> > 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.
> 
> My mistake — this is indeed problematic.
> 
> There are four possible ways to expose pebs_fmt to the guest when
> cpu->migratable = true:
> 
> 1. Add a pebs_fmt option similar to lbr_fmt.
> This may work, but is not user-friendly and adds unnecessary complexity.
> 
> 2. Set feat_names[8] = feat_names[9] = ... = "pebs-fmt".
> This violates the implicit rule that feat_names[] entries should be
> unique, and target/i386 does not support numeric features.
> 
> 3. Use feat_names[8..11] = "pebs-fmt[1/2/3/4]".
> This has two issues:
> - It exposes pebs-fmt[1/2/3/4] as independent features, which is
> semantically incorrect.
> - Migration may fail incorrectly; e.g., migrating from pebs_fmt=2 to a
> more capable host (pebs_fmt=4) would be reported as missing pebs-fmt2.

For 2) & 3), I think if it's necessary, maybe it's time to re-consider
the previous multi-bits property:

https://lore.kernel.org/qemu-devel/20230106083826.5384-4-lei4.wang@intel.com/

But as for now, I think 1) is also okay. Since lbr-fmt seems very
similar to pebs-fmt, it's best to have them handle these fmt things in a
similar manner, otherwise it can make code maintenance troublesome.

> Given this, I propose the below changes. This may allow migration to a
> less capable destination, which is not ideal, but it avoids false
> “missing feature” bug and preserves the expectation that ensuring
> destination compatibility is the responsibility of the management
> application or the user.
> 
> BTW, I am not proposing a generic “x86 CPU numeric feature” mechanism at
> this time, as it is unclear whether lbr_fmt and pebs_fmt alone justify
> such a change.
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 015ba3fc9c7b..b6c95d5ceb31 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -1629,6 +1629,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
>          .msr = {
>              .index = MSR_IA32_PERF_CAPABILITIES,
>          },
> +       .migratable_flags = PERF_CAP_PEBS_FMT,

About the migration issue, I wonder whether it's necessary to migrate
pebs-fmt? IIUC, it seems not necessary: the guest's pebs-fmt depends on
host's pebs-fmt, but I'm sure what will happens when guest migrates to
a mahince with different pebs-fmt.

note, lbr-fmt seems not be migrated.

Thanks,
Zhao