Re: [Xen-devel] [PATCH] x86/intel: Protect set_cpuidmask() against #GP faults

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.06.14 at 13:19, <andrew.cooper3@xxxxxxxxxx> wrote:
> Virtual environments such as Xen HVM containers and VirtualBox do not
> necessarily provide support for feature masking MSRs.
> 
> As their presence is detected by model numbers alone, and their use 
> predicated
> on command line parameters, use the safe() variants of {wr,rd}msr() to avoid
> dying with an early #GP fault.

I'm tempted to say "Then just don't pass these options." There are
other options that can lead to boot failure if not used properly.

> * Call set_cpuidmask() unconditionally so faulting-capable hardware still gets
>   a log message indicating to the user why their command line arguments are
>   not taking effect.

I don't think Intel will particularly like this part.

> -     /* Only family 6 supports this feature  */
> -     switch ((c->x86 == 6) * c->x86_model) {
> -     case 0x17:
> -             if ((c->x86_mask & 0x0f) < 4)
> -                     break;

I had been inquiring about this stepping specific check here too,
without ever getting clarification. I think we shouldn't blindly
drop it.

> + setmask:
> +     if (msr_basic &&
> +         wrmsr_safe(msr_basic,
> +                    ((u64)opt_cpuid_mask_edx << 32) | opt_cpuid_mask_ecx)){
> +             msr_basic = 0;
> +             printk("Failed to set CPUID feature mask\n");
> +     }
> +
> +     if (msr_ext &&
> +         wrmsr_safe(msr_ext,
> +                    ((u64)opt_cpuid_mask_ext_edx << 32) | 
> opt_cpuid_mask_ext_ecx)){
> +             msr_ext = 0;
> +             printk("Failed to set CPUID extended feature mask\n");
> +     }
> +
> +     if (msr_xsave &&
> +         (rdmsr_safe(msr_xsave, msr_val) ||
> +          wrmsr_safe(msr_xsave,
> +                     ((u64)msr_val << 32) | opt_cpuid_mask_xsave_eax))){

I'm afraid copy'n'paste went a little too far here: Neither does msr_val
need a u64 cast, nor do you want to write into the high half what you
read from the low one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel