On Wed, Dec 22, 2021 at 5:34 AM Like Xu <like.xu.linux@xxxxxxxxx> wrote: > > From: Like Xu <likexu@xxxxxxxxxxx> > > The aperf/mperf are used to report current CPU frequency after 7d5905dc14a. > But guest kernel always reports a fixed vCPU frequency in the /proc/cpuinfo, > which may confuse users especially when turbo is enabled on the host or > when the vCPU has a noisy high power consumption neighbour task. > > Most guests such as Linux will only read accesses to AMPERF msrs, where > we can passthrough registers to the vcpu as the fast-path (a performance win) > and once any write accesses are trapped, the emulation will be switched to > slow-path, which emulates guest APERF/MPERF values based on host values. > In emulation mode, the returned MPERF msr value will be scaled according > to the TSCRatio value. > > As a minimum effort, KVM exposes the AMPERF feature when the host TSC > has CONSTANT and NONSTOP features, to avoid the need for more code > to cover various coner cases coming from host power throttling transitions. > > The slow path code reveals an opportunity to refactor update_vcpu_amperf() > and get_host_amperf() to be more flexible and generic, to cover more > power-related msrs. > > Requested-by: Dongli Cao <caodongli@xxxxxxxxxxxx> > Requested-by: Li RongQing <lirongqing@xxxxxxxxx> > Signed-off-by: Like Xu <likexu@xxxxxxxxxxx> I am not sure that it is necessary for kvm to get involved in the virtualization of APERF and MPERF at all, and I am highly skeptical of the need for passing through the hardware MSRs to a guest. Due to concerns over potential side-channel exploits a la Platypus (https://platypusattack.com/), we are planning to provide only low fidelity APERF/MPERF virtualization from userspace, using the userspace MSR exiting mechanism. Of course, we should be able to do that whether or not this change goes in, but I was wondering if you could provide some more details regarding your use case(s).
