>>> On 21.08.18 at 15:59, <jgr...@suse.com> wrote:
> On 21/08/18 14:40, Jan Beulich wrote:
>>>>> On 21.08.18 at 14:13, <jgr...@suse.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
