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.
