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