Re: [PATCH 0/4] Virtualize architectural LBRs

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.12.2024 15:16, Tu Dinh wrote:
> On 18/11/2024 10:52, Andrew Cooper wrote:
>> On 18/11/2024 9:13 am, Tu Dinh wrote:
>>> On 18/11/2024 09:52, Jan Beulich wrote:
>>>> Looking over just the files touched: No change to XSAVE logic at all?
>>> XSAVE is hidden behind a new IA32_XSS bit. I'll try to implement that next.
>>
>> It's rather more severe than that.
>>
>> Without XSAVE support, Xen can't context-switch the LBR state when vCPUs
>> are scheduled in and out.  (In patch 4 you seem to have copied the
>> legacy way, which is extremely expensive.)
>>
>> Architecturally, ARCH_LBR depends on XSAVES so OSes can context switch
>> it easily(ish) per thread.
>>
>> There's also a reason why we haven't got this working yet.  There are a
>> couple of areas of prerequisite work which need addressing before XSS
>> can be enabled properly.
>>
>> If you're willing to tackle this, then I can explain what needs doing,
>> and in roughly which order.
> 
> Following the community call yesterday, I'd like to clarify my 
> understanding of the issue:
> 
> - Firstly, virtual XSS support for architectural LBR must be enabled. I 
> noticed that XSS is already implemented, just not enabled; barring the 
> LBR format issues below, are there any other issues with the current XSS 
> implementation?

At the very least, as with any code that exists be is effectively unused
(and iiuc even DCE-ed by the compiler in at least some of the cases) it'll
need to be determined whether what we have actually works. It seems more
likely than not that some corrections here and there may be needed.

> - There are LBR format differences between some cores of the same CPU 
> (e.g. in Intel hybrid CPUs: P-cores use effective IP while E-cores use 
> linear IP). These differences are expected to be handled by 
> XSAVES/XRSTORS. However, Xen would have to make sure that LBR MSRs are 
> saved/restored by XSS instead of by manually poking MSRs.

How could XSAVES/XRSTORS take care of format differences? Something that
was saved on one type of core and is to be restored on the other type of
core would require CS.base at the time the LBR was originally written
to be able to convert effective <=> linear IP.

> - A related issue is handling the compressed XSAVE format for migration 
> streams. Xen currently expands/compacts XSAVE format manually during 
> migration; are there any concerns with arch LBR breaking the XSAVE 
> migration logic?

That ought to be fine, I think, barring the first point I made above.

Jan