mbox series

[0/4] Virtualize architectural LBRs

Message ID 20241118084914.22268-1-ngoc-tu.dinh@vates.tech (mailing list archive)
Headers show
Series Virtualize architectural LBRs | expand

Message

Tu Dinh Nov. 18, 2024, 8:49 a.m. UTC
From: Tu Dinh <ngoc-tu.dinh@vates.tech>

Intel model-specific last branch records (LBRs) were replaced by
architectural LBRs (see Chapter 20 of Intel SDM volume 3B). This
patchset implements virtual LBRs for HVM guests using Intel's "load
guest IA32_LBR_CTL" and "clear IA32_LBR_CTL" VMX controls.

Add the necessary CPUID and VMX feature checks into Xen. Note that in
this patchset, MSR_IA32_LASTBRANCH_DEPTH is only allowed to be equal to
that of the host's.

Tu Dinh (4):
  x86: Add Intel architectural LBR featureset bits
  x86: Add architectural LBR declarations
  x86: Adjust arch LBR CPU policy
  x86/vmx: Virtualize architectural LBRs

 tools/libs/guest/xg_cpuid_x86.c             |   2 +-
 tools/misc/xen-cpuid.c                      |   3 +
 xen/arch/x86/cpu-policy.c                   |  39 +++
 xen/arch/x86/cpu/common.c                   |   7 +
 xen/arch/x86/hvm/vmx/vmcs.c                 |  11 +-
 xen/arch/x86/hvm/vmx/vmx.c                  | 269 ++++++++++++++------
 xen/arch/x86/include/asm/hvm/vmx/vmcs.h     |   8 +
 xen/arch/x86/include/asm/msr-index.h        |  11 +
 xen/include/public/arch-x86/cpufeatureset.h |  28 +-
 xen/include/xen/lib/x86/cpu-policy.h        |  38 ++-
 xen/lib/x86/cpuid.c                         |   6 +
 11 files changed, 339 insertions(+), 83 deletions(-)

Comments

Jan Beulich Nov. 18, 2024, 8:52 a.m. UTC | #1
On 18.11.2024 09:49, ngoc-tu.dinh@vates.tech wrote:
> From: Tu Dinh <ngoc-tu.dinh@vates.tech>
> 
> Intel model-specific last branch records (LBRs) were replaced by
> architectural LBRs (see Chapter 20 of Intel SDM volume 3B). This
> patchset implements virtual LBRs for HVM guests using Intel's "load
> guest IA32_LBR_CTL" and "clear IA32_LBR_CTL" VMX controls.
> 
> Add the necessary CPUID and VMX feature checks into Xen. Note that in
> this patchset, MSR_IA32_LASTBRANCH_DEPTH is only allowed to be equal to
> that of the host's.
> 
> Tu Dinh (4):
>   x86: Add Intel architectural LBR featureset bits
>   x86: Add architectural LBR declarations
>   x86: Adjust arch LBR CPU policy
>   x86/vmx: Virtualize architectural LBRs
> 
>  tools/libs/guest/xg_cpuid_x86.c             |   2 +-
>  tools/misc/xen-cpuid.c                      |   3 +
>  xen/arch/x86/cpu-policy.c                   |  39 +++
>  xen/arch/x86/cpu/common.c                   |   7 +
>  xen/arch/x86/hvm/vmx/vmcs.c                 |  11 +-
>  xen/arch/x86/hvm/vmx/vmx.c                  | 269 ++++++++++++++------
>  xen/arch/x86/include/asm/hvm/vmx/vmcs.h     |   8 +
>  xen/arch/x86/include/asm/msr-index.h        |  11 +
>  xen/include/public/arch-x86/cpufeatureset.h |  28 +-
>  xen/include/xen/lib/x86/cpu-policy.h        |  38 ++-
>  xen/lib/x86/cpuid.c                         |   6 +
>  11 files changed, 339 insertions(+), 83 deletions(-)

Looking over just the files touched: No change to XSAVE logic at all?

Jan
Tu Dinh Nov. 18, 2024, 9:13 a.m. UTC | #2
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.


Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech
Andrew Cooper Nov. 18, 2024, 9:52 a.m. UTC | #3
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
Tu Dinh Nov. 18, 2024, 2:37 p.m. UTC | #4
On 18/11/2024 10:52, Andrew Cooper wrote:
> 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.

I would appreciate explanations of the pending XSS issues.


Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech