On Thu, Jun 9, 2022 at 6:47 PM Yang, Weijiang <weijiang.yang@xxxxxxxxx> wrote: > > > On 6/10/2022 8:14 AM, Like Xu wrote: > > On 9/6/2022 4:39 pm, Yang Weijiang wrote: > >> executing rdpmc leads to #GP, > > > > RDPMC still works on processors that do not support architectural > > performance monitoring. > > > > The #GP will violate ISA, and try to treat it as NOP (plus EAX=EDX=0) > > if !enable_pmu. > > After a quick check in SDM, I cannot find wordings supporting your above > comments, can you > > point me to it? In volume 2, under RDPMC... o If the processor does not support architectural performance monitoring (CPUID.0AH:EAX[7:0]=0), ECX[30:0] specifies the index of the PMC to be read. Setting ECX[31] selects “fast” read mode if supported. In this mode, RDPMC returns bits 31:0 of the PMC in EAX while clearing EDX to zero. For more details, see the following sections of volume 3: 19.6.3 Performance Monitoring (Processors Based on Intel NetBurst Microarchitecture) 19.6.8 Performance Monitoring (P6 Family Processor) 19.6.9 Performance Monitoring (Pentium Processors) > Another concern is, when !enable_pmu, should we make RDPMC "work" with > returning EAX=EDX=0? > > Or just simply inject #GP to VM in this case? Unless KVM is running on a Prescott, it's going to be very difficult to emulate one of these three pre-architectural performance monitoring PMUs. There certainly isn't any code to do it today. In fact, there is no code in KVM to virtualize the NetBurst PMU, even on Prescott. I think Like is being overly pedantic (which is usually my role). RDPMC should behave exactly the same way that RDMSR behaves when accessing the same counter. The last time I looked, RDMSR synthesizes #GP for PMC accesses when !enable_pmu.
