Re: [PATCH 0/4] Virtualize architectural LBRs

["Tu Dinh" <ngoc-tu.dinh@xxxxxxxxxx>]

Hi Andrew,

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.
>
> ~Andrew

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?

- 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.

- 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?

My understanding is that as long as we don't manually poke the LBR state
component, and that LBR state size remains consistent across hybrid
cores in the same CPU (which it should be for XSAVE compatibility),
there should be no concern with the XSAVE state itself. However, Xen
must check CPU features of both sides during migration to make sure that
XSAVE states are compatible, which is more complex in migrations
involving hosts with hybrid CPUs.

Please tell me if I'm missing any potential issues.

Thanks,


Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech