[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen stable-4.17] x86/vmx: Support for CPUs without model-specific LBR
commit e904d8ae01a0be53368c8c388f13bf4ffcbcdf6c Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> AuthorDate: Tue Feb 7 16:59:14 2023 +0100 Commit: Jan Beulich <jbeulich@xxxxxxxx> CommitDate: Tue Feb 7 16:59:14 2023 +0100 x86/vmx: Support for CPUs without model-specific LBR Ice Lake (server at least) has both architectural LBR and model-specific LBR. Sapphire Rapids does not have model-specific LBR at all. I.e. On SPR and later, model_specific_lbr will always be NULL, so we must make changes to avoid reliably hitting the domain_crash(). The Arch LBR spec states that CPUs without model-specific LBR implement MSR_DBG_CTL.LBR by discarding writes and always returning 0. Do this for any CPU for which we lack model-specific LBR information. Adjust the now-stale comment, now that the Arch LBR spec has created a way to signal "no model specific LBR" to guests. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> master commit: 3edca52ce736297d7fcf293860cd94ef62638052 master date: 2023-01-12 18:42:00 +0000 --- xen/arch/x86/hvm/vmx/vmx.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ad91464103..861f91f2af 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3545,18 +3545,26 @@ static int cf_check vmx_msr_write_intercept( if ( msr_content & rsvd ) goto gp_fault; + /* + * The Arch LBR spec (new in Ice Lake) states that CPUs with no + * model-specific LBRs implement MSR_DBG_CTL.LBR by discarding writes + * and always returning 0. + * + * Use this property in all cases where we don't know any + * model-specific LBR information, as it matches real hardware + * behaviour on post-Ice Lake systems. + */ + if ( !model_specific_lbr ) + msr_content &= ~IA32_DEBUGCTLMSR_LBR; + /* * When a guest first enables LBR, arrange to save and restore the LBR * MSRs and allow the guest direct access. * - * MSR_DEBUGCTL and LBR has existed almost as long as MSRs have - * existed, and there is no architectural way to hide the feature, or - * fail the attempt to enable LBR. - * - * Unknown host LBR MSRs or hitting -ENOSPC with the guest load/save - * list are definitely hypervisor bugs, whereas -ENOMEM for allocating - * the load/save list is simply unlucky (and shouldn't occur with - * sensible management by the toolstack). + * Hitting -ENOSPC with the guest load/save list is definitely a + * hypervisor bug, whereas -ENOMEM for allocating the load/save list + * is simply unlucky (and shouldn't occur with sensible management by + * the toolstack). * * Either way, there is nothing we can do right now to recover, and * the guest won't execute correctly either. Simply crash the domain @@ -3567,13 +3575,6 @@ static int cf_check vmx_msr_write_intercept( { const struct lbr_info *lbr = model_specific_lbr; - if ( unlikely(!lbr) ) - { - gprintk(XENLOG_ERR, "Unknown Host LBR MSRs\n"); - domain_crash(v->domain); - return X86EMUL_OKAY; - } - for ( ; lbr->count; lbr++ ) { unsigned int i; -- generated by git-patchbot for /home/xen/git/xen.git#stable-4.17
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |