>>> On 19.07.18 at 13:44, <[email protected]> wrote: > --- a/xen/arch/x86/xstate.c > +++ b/xen/arch/x86/xstate.c > @@ -707,12 +707,32 @@ int handle_xsetbv(u32 index, u64 new_bv) > if ( index != XCR_XFEATURE_ENABLED_MASK ) > return -EOPNOTSUPP; > > - if ( (new_bv & ~xcr0_max) || > - (new_bv & ~xfeature_mask) || !valid_xcr0(new_bv) ) > + /* > + * The CPUID logic shouldn't be able to hand out an XCR0 exceeding Xen's > + * maximum features, but keep the check for robustness. > + */ > + if ( unlikely(xcr0_max & ~xfeature_mask) ) > + { > + gprintk(XENLOG_ERR, > + "xcr0_max %016" PRIx64 " exceeds hardware max %016" PRIx64 > "\n", > + new_bv, xfeature_mask);
I've only noticed this while doing the 4.8 backport: I don't think you've meant to log new_bv here, rather than xcr0_max. Jan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
