> > > > Suppose your KVM thing claims counter 0/2 (ICL/SKL) for some > > > > random PEBS event, and then the host wants to use PREC_DIST.. Then > > > > one of them will be screwed for no reason what so ever. > > > > > > > > > > The multiplexing should be triggered. > > > > > > For host, if both user A and user B requires PREC_DIST, the > > > multiplexing should be triggered for them. > > > Now, the user B is KVM. I don't think there is difference. The > > > multiplexing should still be triggered. Why it is screwed? > > > > Becuase if KVM isn't PREC_DIST we should be able to reschedule it to a > > different counter. > > > > > > How is that not destroying scheduling freedom? Any other situation > > > > we'd have moved the !PREC_DIST PEBS event to another counter. > > > > > > > > > > All counters are equivalent for them. It doesn't matter if we move > > > it to another counter. There is no impact for the user. > > > > But we cannot move it to another counter, because you're pinning it. > > Hi Peter, > > To avoid the pinning counters, I have tried to do some evaluation about > patching the PEBS record for guest in KVM. In this approach, about ~30% time > increased on guest PEBS PMI handler latency ( e.g.perf record -e branch- > loads:p -c 1000 ~/Tools/br_instr a). > > Some implementation details as below: > 1. Patching the guest PEBS records "Applicable Counters" filed when the guest > required counter is not the same with the host. Because the guest PEBS > driver will drop these PEBS records if the "Applicable Counters" not the > same with the required counter index. > 2. Traping the guest driver's behavior(VM-exit) of disabling PEBS. > It happens before reading PEBS records (e.g. PEBS PMI handler, before > application exit and so on) > 3. To patch the Guest PEBS records in KVM, we need to get the HPA of the > guest PEBS buffer. > <1> Trapping the guest write of IA32_DS_AREA register and get the GVA > of guest DS_AREA. > <2> Translate the DS AREA GVA to GPA(kvm_mmu_gva_to_gpa_read) > and get the GVA of guest PEBS buffer from DS AREA > (kvm_vcpu_read_guest_atomic). > <3> Although we have got the GVA of PEBS buffer, we need to do the > address translation(GVA->GPA->HPA) for each page. Because we can't > assume the GPAs of Guest PEBS buffer are always continuous. > > But we met another issue about the PEBS counter reset field in DS AREA. > pebs_event_reset in DS area has to be set for auto reload, which is per counter. > Guest and Host may use different counters. Let's say guest wants to use > counter 0, but host assign counter 1 to guest. Guest sets the reset value to > pebs_event_reset[0]. However, since counter 1 is the one which is eventually > scheduled, HW will use pebs_event_reset[1] as reset value. > > We can't copy the value of the guest pebs_event_reset[0] to > pebs_event_reset[1] directly(Patching DS AREA) because the guest driver may > confused, and we can't assume the guest counter 0 and 1 are not used for this > PEBS task at the same time. And what's more, KVM can't aware the guest > read/write to the DS AREA because it just a general memory for guest. > > What is your opinion or do you have a better proposal? Kindly ping~ Thanks, Luwei Kang > > Thanks, > Luwei Kang > > > > > > In the new proposal, KVM user is treated the same as other host > > > events with event constraint. The scheduler is free to choose > > > whether or not to assign a counter for it. > > > > That's what it does, I understand that. I'm saying that that is > > creating artificial contention. > > > > > > Why is this needed anyway? Can't we force the guest to flush and then > > move it over to a new counter?
