On Wed, May 24, 2023 at 1:41 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > 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. The reverse problem occurs when a PMC is configured to count "CPUID instructions retired." Since KVM intercepts CPUID and emulates it, the PMC will always read 0, even if the guest executes a tight loop of CPUID instructions. The PMU is not virtualizable on AMD CPUs without significant hypervisor corrections. I have to wonder if it's really worth the effort.
