On Wed, Dec 04, 2024, Jim Mattson wrote:
> Wherever the context-switching happens, I contend that there is no
> "clean" virtualization of APERF. If it comes down to just a question
> of VM-entry/VM-exit or vcpu_load()/vcpu_put(), we can collect some
> performance numbers and try to come to a consensus, but if you're
> fundamentally opposed to virtualizing APERF, because it's messy, then
> I don't see any point in pursuing this further.
I'm not fundamentally opposed to virtualizing the feature. My complaints with
the series are that it doesn't provide sufficient information to make it feasible
for reviewers to provide useful feedback. The history you provided is a great
start, but that's still largely just background information. For a feature as
messy and subjective as APERF/MPERF, I think we need at least the following:
1. What use cases are being targeted (e.g. because targeting only SoH would
allow for a different implementation).
2. The exact requirements, especially with respect to host usage. And the
the motivation behind those requirements.
3. The high level design choices, and what, if any, alternatives were considered.
4. Basic rules of thumb for what is/isn't accounted in APERF/MPERF, so that it's
feasible to actually maintain support long-term.
E.g. does the host need to retain access to APERF/MPERF at all times? If so, why?
Do we care about host kernel accesses, e.g. in the scheduler, or just userspace
accesses, e.g. turbostat?
What information is the host intended to see? E.g. should APERF and MPERF stop
when transitioning to the guest? If not, what are the intended semantics for the
host's view when running VMs with HLT-exiting disabled? If the host's view of
APERF and MPREF account guest time, how does that mesh with upcoming mediated PMU,
where the host is disallowed from observing the guest?
Is there a plan for supporting VMs with a different TSC frequency than the host?
How will live migration work, without generating too much slop/skew between MPERF
and GUEST_TSC?
I don't expect the series to answer every possible question upfront, but the RFC
provided _nothing_, just a "here's what we implemented, please review".
