On 1/25/2026 12:38 AM, Zhao Liu wrote:
> 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/[email protected]/
I think the multi-bit property may be a better approach (which I
previously referred to as “numeric features”).
As Igor pointed out, this would involve an infrastructure change, so I
am hesitant to pursue it at this time.
> 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.
Yes, it works. Will post V2 with this approach.
>> 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.
For a migratable feature, it's related state should be fully captured in
the VM migration stream. Both the LBR and PEBS states are serialized
via vmstate, so it may not be wrong to call labr/pebs_fmt a migratable
feature.
However, QEMU must provide means—either to external management
applications via QOM properties or to users via command-line options—to
ensure that the destination machine supports all features enabled on the
source. The current migratable_flags proposal does not address this.
My original intention was to treat this as a workaround.
> Thanks,
> Zhao
>
