On 16/07/18 13:53, Jan Beulich wrote:
>>>> On 16.07.18 at 14:37, <andrew.coop...@citrix.com> wrote:
>> On 13/07/18 09:13, Jan Beulich wrote:
>>>>>> On 12.07.18 at 17:45, <andrew.coop...@citrix.com> wrote:
>>>> On 11/07/18 13:10, Jan Beulich wrote:
>>>>> --- a/docs/misc/xen-command-line.markdown
>>>>> +++ b/docs/misc/xen-command-line.markdown
>>>>> @@ -1040,6 +1040,13 @@ identical to the boot CPU will be parked
>>>>> ### hpetbroadcast (x86)
>>>>> > `= <boolean>`
>>>>>
>>>>> +### ht (x86)
>>>> I'd suggest smt rather than ht here. SMT is the technical term, while
>>>> HT is Intel's marketing name.
>>> Hmm, many BIOSes (if the have such an option) talk about HT, which
>>> to me makes "ht" a closer match. How about we allow both?
>> That's because a BIOS is custom to the hardware it runs on.
>>
>> Have you tried setting up an alias before? (given the specific
>> deficiency of the *_param() infrastructure in this area) I'm don't
>> think an alias is worth the effort.
> This reads as if you were expecting problems. Instead of
>
> +int8_t __read_mostly opt_ht = -1;
> +boolean_param("ht", opt_ht);
>
> what we'd have is simply
>
> +int8_t __read_mostly opt_ht = -1;
> +boolean_param("ht", opt_ht);
> +boolean_param("smt", opt_ht);
>
> (and whether we use opt_ht or opt_smt doesn't matter much
> to me). I don't see any source of possible issues with this.
Try compiling it.
I tried exactly this with bti= and spec-ctrl= originally. The problem
is that the second argument must be (translation unit) unique, because
of the way it is used to form the name of the struct kernel_param.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
