Re: [PATCH v2 4/4] KVM: x86: Expose Architectural LBR CPUID and its XSAVES bit

[Paolo Bonzini]

On 07/02/21 02:02, Xu, Like wrote:
> On 2021/2/5 19:00, Paolo Bonzini wrote:
> > On 05/02/21 09:16, Xu, Like wrote:
> > > Hi Paolo,
> > >
> > > I am wondering if it is acceptable for you to
> > > review the minor Architecture LBR patch set without XSAVES for v5.12 ?
> > >
> > > As far as I know, the guest Arch LBR  can still work without XSAVES 
> > > support.
> >
> > I dopn't think it can work.  You could have two guests on the same 
> > physical CPU and the MSRs would be corrupted if the guests write to 
> > the MSR but they do not enable the LBRs.
> >
> > Paolo
> Neither Arch LBR nor the old version of LBR have this corruption issue,
> and we will not use XSAVES for at least LBR MSRs in the VMX transaction.
>
> This is because we have reused the LBR save/restore swicth support from the
> host perf mechanism in the legacy LBR support, which will save/restore 
> the LBR
> MSRs of the vcpu (thread) when the vcpu is sched in/out.
>
> Therefore, if we have two guests on the same physical CPU, the usage of 
> LBR MSRs
> is isolated, and it's also true when we use LBR to trace the hypervisor 
> on the host.
> The same thing happens on the platforms which supports Arch LBR.
>
> I propose that we don't support using XSAVES to save/restore Arch LRB 
> *in the guest*
> (just like the guest Intel PT), but use the traditional RD/WRMSR, which 
> still works
> like the legacy LBR.

Ok, this makes sense.  I'll review the patches more carefully, looking 
at 5.13 for the target.

Paolo

> Since we already have legacy LBR support, we can add a small amount of 
> effort (just
> two more MSRs emulation and related CPUID exposure) to support Arch LBR 
> w/o XSAVES.
>
> I estimate that there are many issues we need to address when we 
> supporting guests
> to use xsaves instructions. As a rational choice, we could enable the 
> basic Arch LBR.
>
> Paolo and Sean, what do you think ?
>
> ---
> thx, likexu