Messages in this thread | | | Date | Wed, 11 Oct 2023 16:15:35 +0200 | From | Peter Zijlstra <> | Subject | Re: [Patch v4 07/13] perf/x86: Add constraint for guest perf metrics event |
| |
On Mon, Oct 09, 2023 at 10:33:41PM +0530, Manali Shukla wrote: > Hi all, > > I would like to add following things to the discussion just for the awareness of > everyone. > > Fully virtualized PMC support is coming to an upcoming AMD SoC and we are > working on prototyping it. > > As part of virtualized PMC design, the PERF_CTL registers are defined as Swap > type C: guest PMC states are loaded at VMRUN automatically but host PMC states > are not saved by hardware.
Per the previous discussion, doing this while host has active counters that do not have ::exclude_guest=1 is invalid and must result in an error.
Also, I'm assuming it is all optional, a host can still profile a guest if all is configured just so?
> If hypervisor is using the performance counters, it > is hypervisor's responsibility to save PERF_CTL registers to host save area > prior to VMRUN and restore them after VMEXIT.
Does VMEXIT clear global_ctrl at least?
> In order to tackle PMC overflow > interrupts in guest itself, NMI virtualization or AVIC can be used, so that > interrupt on PMC overflow in guest will not leak to host.
Can you please clarify -- AMD has this history with very dodgy PMI boundaries. See the whole amd_pmu_adjust_nmi_window() crud. Even the PMUv2 update didn't fix that nonsense.
How is any virt stuff supposed to fix this? If the hardware is late delivering PMI, what guarantees a guest PMI does not land in host context and vice-versa?
How does NMI virtualization (what even is that) or AVIC (I'm assuming that's a virtual interrupt controller) help?
Please make very sure, with your hardware team, that PMI must not be delivered after clearing global_ctrl (preferably) or at the very least, there exists a sequence of operations that provides a hard barrier to order PMI.
| |