On 21/08/18 14:04, Juergen Gross wrote:
> On 21/08/18 12:44, Jan Beulich wrote:
>> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
>> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
>> this then became equivalent to "xpti=no". In particular, the presence
>> of "xpti=" alone on the command line means nothing as to which
>> default is to be overridden; "xpti=no-dom0" ought to have no effect
>> for DomU-s (and vice versa), as this is distinct from both
>> "xpti=no-dom0,domu" and "xpti=no-dom0,no-domu".
>>
>> Here as well as for "pv-l1tf=" I think there's no way around tracking
>> the "use default" state separately for Dom0 and DomU-s. Introduce
>> individual bits for this, and convert the variables' types (back) to
>> uint8_t.
>>
>> Additionally the earlier change claimed to have got rid of the
>> 'parameter "xpti" has invalid value "", rc=-22!' log message for "xpti"
>> alone on the command line, which wasn't the case (the option took effect
>> nevertheless). Fix this as well.
>>
>> Finally also support a "default" sub-option for "pv-l1tf=", just like
>> "xpti=" does.
>>
>> It is perhaps worth to note that OPT_<what>_DOM<which>_DEFAULT set
>> implies OPT_<what>_DOM<which> clear, which is being utilized in a number
>> of places (we effectively want to hold two tristates in a single
>> variable, which means the fourth state is impossible).
>
> Another possibility would be to have two local variables holding the
> bits to clear and to set and to apply those after each sub-option
> parsed.
Ignore please, hit send instead of cancel.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
