Re: [Xen-devel] [PATCH] x86: fix "xpti=" and "pv-l1tf=" yet again

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.08.18 at 15:59, <jgross@xxxxxxxx> wrote:
> On 21/08/18 14:40, Jan Beulich wrote:
>>>>> On 21.08.18 at 14:13, <jgross@xxxxxxxx> wrote:
>>> On 21/08/18 12:44, Jan Beulich wrote:
>>>> @@ -219,17 +216,13 @@ static int __init parse_spec_ctrl(const
>>>>  }
>>>>  custom_param("spec-ctrl", parse_spec_ctrl);
>>>>  
>>>> -int8_t __read_mostly opt_pv_l1tf = -1;
>>>> +uint8_t __read_mostly opt_pv_l1tf = OPT_PV_L1TF_DOMU_DEFAULT;
>>>>  
>>>>  static __init int parse_pv_l1tf(const char *s)
>>>>  {
>>>>      const char *ss;
>>>>      int val, rc = 0;
>>>>  
>>>> -    /* Inhibit the defaults as an explicit choice has been given. */
>>>> -    if ( opt_pv_l1tf == -1 )
>>>> -        opt_pv_l1tf = 0;
>>>
>>> Wouldn't setting the default value (DOMU) here be enough? Same for
>>> xpti below?
>> 
>> No, because we want to defer default processing until we've
>> actually obtained the necessary data. While parsing we don't
>> know yet whether "default" means "on" or "off".
>> 
>> Or perhaps I don't understand what you mean?
> 
> I meant:
> 
>      if ( opt_pv_l1tf == -1 )
> -        opt_pv_l1tf = 0;
> +        opt_pv_l1tf = OPT_PV_L1TF_DOMU;
> 
> This starts at the default setting and then applies the settings of the
> sub-options on top of it, instead of starting at "everything off".

Well, as said - this would get in the way of

    if ( (opt_pv_l1tf & OPT_PV_L1TF_DOMU_DEFAULT) &&
         !pv_shim && cpu_has_bug_l1tf )
        opt_pv_l1tf |= OPT_PV_L1TF_DOMU;

close to the end of the patch. IOW "pv-l1tf=dom0" as well
as "pv-l1tf=no-dom0" ought to leave DomU-s running
without the workaround on fixed hardware.

Jan



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