Re: [PATCH 5/5] KVM: x86/pmu: Hide guest counter updates from the VMRUN instruction

[Sean Christopherson]

On Wed, Apr 26, 2023, Sandipan Das wrote:
> Hi Sean, Like,
> 
> On 4/19/2023 7:11 PM, Like Xu wrote:
> >> Heh, it's very much explicable, it's just not desirable, and you and I would argue
> >> that it's also incorrect.
> > 
> > This is completely inaccurate from the end guest pmu user's perspective.
> > 
> > I have a toy that looks like virtio-pmu, through which guest users can get hypervisor performance data.
> > But the side effect of letting the guest see the VMRUN instruction by default is unacceptable, isn't it ?
> > 
> >>
> >> AMD folks, are there plans to document this as an erratum?� I agree with Like that
> >> counting VMRUN as a taken branch in guest context is a CPU bug, even if the behavior
> >> is known/expected.
> > 
> 
> This behaviour is architectural and an erratum will not be issued. However, for clarity, a future
> release of the APM will include additional details like the following:
> 
>   1) From the perspective of performance monitoring counters, VMRUNs are considered as far control
>      transfers and VMEXITs as exceptions.
> 
>   2) When the performance monitoring counters are set up to count events only in certain modes
>      through the "OsUserMode" and "HostGuestOnly" bits, instructions and events that change the
>      mode are counted in the target mode. For example, a SYSCALL from CPL 3 to CPL 0 with a
>      counter set to count retired instructions with USR=1 and OS=0 will not cause an increment of
>      the counter. However, the SYSRET back from CPL 0 to CPL 3 will cause an increment of the
>      counter and the total count will end up correct. Similarly, when counting PMCx0C6 (retired
>      far control transfers, including exceptions and interrupts) with Guest=1 and Host=0, a VMRUN
>      instruction will cause an increment of the counter. However, the subsequent VMEXIT that occurs,
>      since the target is in the host, will not cause an increment of the counter and so the total
>      count will end up correct.

The count from the guest's perspective does not "end up correct".  Unlike SYSCALL,
where _userspace_ deliberately and synchronously executes a branch instruction,
VMEXIT and VMRUN are supposed to be transparent to the guest and can be completely
asynchronous with respect to guest code execution, e.g. if the host is spamming
IRQs, the guest will see a potentially large number of bogus (from it's perspective)
branches retired.