On Wed, Oct 26, 2022, 7:06 AM Andrew Cooper <[email protected]> wrote:
> On 24/10/2022 17:58, Tamas K Lengyel wrote: > > Currently the XEN_DOMCTL_get_vcpu_msrs is only capable of gathering a > handful > > of predetermined vcpu MSRs. In our use-case gathering the vPMU MSRs by an > > external privileged tool is necessary, thus we extend the domctl to > allow for > > querying for any guest MSRs. To remain compatible with the existing > setup if > > no specific MSR is requested via the domctl the default list is returned. > > > > Signed-off-by: Tamas K Lengyel <[email protected]> > > Naming aside, XEN_DOMCTL_{get,set}_vcpu_msrs is supposed to be "get me > all MSRs needed to migrate a vCPU". (I do intend to retire the > hypercall as part of fixing the Xen side of migration, but that's ages > away) > > It seems like what you want is something more like > XEN_DOMCTL_{rd,wr}msr_list (convenient timing, given the recent ISE > update). I think those would be better as a separate pair of > hypercalls, rather than trying to repurpose an existing hypercall. > > > As for actually getting the values, please fix up guest_{rd,wr}msr() to > access the perf MSRs safely. I know the vpmu MSR handling is in a > tragic state, but this new get_msr subop is making the problem even more > tangled. > Adding a separate hypercall is fine. Unfortunately wiring it into guest_rdmsr failed on the first attempt when I tried. This is because the guest itself will hit that path when it reads its own vpmu msrs. The guest_rdmsr actually fails in that path and a separate fall-back path is where the vpmu do_rdmsr is called. Now if I wire in the vpmu msrs into guest_rdmsr I short circuit the existing setup and it looked like a can of worms. I would have to figure out who is trying to get the vpmu msrs and do things differently based on that, and the only info we have is if v == current. That just looked fragile to me. Tamas >
