On Fri, Aug 26, 2022, Xiaoyao Li wrote: > On 8/25/2022 11:59 PM, Sean Christopherson wrote: > > But ensuring the RTIT_CTL.TraceEn=0 is all that's needed to make VM-Entry happy, > > and if the host isn't using Intel PT, what do we care if other bits that, for all > > intents and purposes are ignored, are lost across VM-Entry/VM-Exit? I gotta > > imaging the perf will fully initialize RTIT_CTL if it starts using PT. > > Personally, I agree with it. > > But I'm not sure if there is a criteria that host context needs to be > unchanged after being virtualized. > > > Actually, if the host isn't actively using Intel PT, can KVM avoid saving the > > other RTIT MSRs? > > I don't think it's a good idea that it requires PT driver never and won't > rely on the previous value of PT MSRs. But it's OK if handing it over to > perf as the idea you gave below. Yep, my thought exactly. > > Even better, can we hand that off to perf? I really dislike KVM making assumptions > > about perf's internal behavior. E.g. can this be made to look like > > you mean let perf subsystem to do the context save/restore staff of host and > KVM focuses on save/restore of guest context, right? Yep! KVM already more or less does this for "regular" PMU MSRs, though in that case perf hands back a list of MSRs+data. But for Intel PT I don't see any point in having KVM do the actual MSR accesses. Tracing has to be turned off _before_ VM-Enter, so using the MSR load/save lists doesn't buy us anything. > I would like to see comment from perf folks on this and maybe need their > help on how to implement.
