On 27/07/18 14:24, Jan Beulich wrote:
>>>> On 19.07.18 at 13:44, <andrew.coop...@citrix.com> 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.
Oops - you're completely correct.
That is an oversight from rearranging the logic.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
