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

Paolo Bonzini
2021-02-08T10:35:42Z

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
>