Re: [PATCH v2 4/6] KVM: x86/pmu: Add pmc->intr to refactor kvm_perf_overflow{_intr}()

[Paolo Bonzini <pbonzini@redhat.com>]

On 12/10/21 23:55, Jim Mattson wrote:
>>
>> Even for tracing the SDM says "Like the value returned by RDTSC, TSC
>> packets will include these adjustments, but other timing packets (such
>> as MTC, CYC, and CBR) are not impacted".  Considering that "stand-alone
>> TSC packets are typically generated only when generation of other timing
>> packets (MTCs and CYCs) has ceased for a period of time", I'm not even
>> sure it's a good thing that the values in TSC packets are scaled and offset.
>>
>> Back to the PMU, for non-architectural counters it's not really possible
>> to know if they count in cycles or not.  So it may not be a good idea to
>> special case the architectural counters.
>
> In that case, what we're doing with the guest PMU is not
> virtualization. I don't know what it is, but it's not virtualization.

It is virtualization even if it is incompatible with live migration to a 
different SKU (where, as you point out below, multiple TSC frequencies 
might also count as multiple SKUs).  But yeah, it's virtualization with 
more caveats than usual.

> Exposing non-architectural events is questionable with live migration,
> and TSC scaling is unnecessary without live migration. I suppose you
> could have a migration pool with different SKUs of the same generation
> with 'seemingly compatible' PMU events but different TSC frequencies,
> in which case it might be reasonable to expose non-architectural
> events, but I would argue that any of those 'seemingly compatible'
> events are actually not compatible if they count in cycles.

I agree.  Support for marshaling/unmarshaling PMU state exists but it's 
more useful for intra-host updates than for actual live migration, since 
these days most live migration will use TSC scaling on the destination.

Paolo

> 
> Unless, of course, Like is right, and the PMU counters do count fractionally.
>