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.
