Re: [Xen-devel] [PATCH 6/6] x86/VT-x: Fix 64bit HVM guests on Harpertown cores

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Dec 28, 2018 at 12:39:36PM +0000, Andrew Cooper wrote:
> c/s fd32dcfe4c "x86/vmx: Don't leak EFER.NXE into guest context" had an
> unintended consequence on Harpertown cores which, as it turns out, don't
> load MSR_EFER fully from the MSR Load List - on reentry to the guest,
> EFER.SCE is clear irrespective of the value in load list.
> 
> This, being catastrophic to 64bit guests, is far worse than the EFER.NXE
> leakage which was trying to be fixed.
> 
> Introduce cpu_bug_msr_ll_efer_sce to encapsulate this partial revert.
> Avoid adding MSR_EFER to the Load Lists on impacted hardware, and
> reintroduce the logic to use the guests EFER.SCE setting.
> 
> In the common case of running 64bit HVM guests, these extra adjustments
> to EFER should only be hit during guest boot.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

LGTM:

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index 0a10b51..3c2c1ec 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -366,8 +366,14 @@ unsigned long hvm_cr4_guest_valid_bits(const struct 
> domain *d, bool restore);
>      (hvm_paging_enabled(v) && ((v)->arch.hvm.guest_cr[4] & X86_CR4_SMEP))
>  #define hvm_smap_enabled(v) \
>      (hvm_paging_enabled(v) && ((v)->arch.hvm.guest_cr[4] & X86_CR4_SMAP))
> -#define hvm_nx_enabled(v) \
> -    ((v)->arch.hvm.guest_efer & EFER_NX)
> +/*
> + * A consequence of not being able to put MSR_EFER in the MSR Load List is
> + * that we can't context switch EFER.NXE correctly for guests.  The guest 
> gets
> + * Xen's value, and has no choice in the matter.
> + */
> +#define hvm_nx_enabled(v)                                         \
> +    ((likely(!cpu_bug_msr_ll_efer_sce) ? (v)->arch.hvm.guest_efer \

Intead of likely(!...) I would use the unlikely(...) variant
because I think it's easier to read.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel