On Fri, Dec 12, 2025 at 10:25:44PM +0000, Colton Lewis wrote:
Oliver Upton oupton@kernel.org writes:
On Tue, Dec 09, 2025 at 08:51:16PM +0000, Colton Lewis wrote:
+enum vcpu_pmu_register_access {
- VCPU_PMU_ACCESS_UNSET,
- VCPU_PMU_ACCESS_VIRTUAL,
- VCPU_PMU_ACCESS_PHYSICAL,
+};
This is confusing. Even when the guest is accessing registers directly on the CPU I'd still call that "hardware assisted virtualization" and not "physical".
It was what I thought described the access pattern. Do you have another naming suggestion?
PMU_STATE_FREE, PMU_STATE_GUEST_OWNED,
- kvm_pmu_set_physical_access(vcpu);
- return true; }
Aren't there a ton of other registers the guest may access before these two? Having generic PMU register accessors would allow you to manage residence of PMU registers from a single spot.
Yes but these are the only two that use the old trap handlers. I also call set_physical_access from my fast path handler that handles all the other registers when partitioned.
The fast path accessors should only be accessing state already loaded on the CPU. If the guest's PMU context isn't loaded on the CPU then it should return to a kernel context and do a full put/load on the vCPU.
I'm not seeing how this all fits together but for lazy loading to work correctly you need to evaluate the state of the vPMU at vcpu_load(). If there exists an enabled PMC, set PMU_STATE_GUEST_OWNED and load it upfront.
Otherwise, default to PMU_STATE_FREE until the next register access and this whole thing resets when the vCPU is scheduled out. I had suggested to you a while back that you should follow a similar model to the debug registers, this is how they behave.
Thanks, Oliver