Re: [Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads
On 16/07/18 13:53, Jan Beulich wrote:
On 16.07.18 at 14:37, wrote:
>> On 13/07/18 09:13, Jan Beulich wrote:
>> On 12.07.18 at 17:45, 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)
> > `= `
>
> +### 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
Re: [Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads
>>> On 16.07.18 at 14:37, wrote:
> On 13/07/18 09:13, Jan Beulich wrote:
> On 12.07.18 at 17:45, 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)
> `= `
+### 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.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads
On 13/07/18 09:13, Jan Beulich wrote: On 12.07.18 at 17:45, 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) >>> > `= ` >>> >>> +### 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. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads
>>> On 12.07.18 at 17:45, 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) >> > `= ` >> >> +### 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? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads
On 11/07/18 13:10, Jan Beulich wrote: > Shared resources (L1 cache and TLB in particular) present a risk of > information leak via side channels. Don't use hyperthreads in such > cases, but allow independent control of their use at the same time. > > Signed-off-by: Jan Beulich > --- > An option to avoid the up/down cycle would be to avoid clearing the > sibling (and then perhaps also core) map of parked CPUs, allowing to > bail early from cpu_up_helper(). > > TBD: How to prevent the CPU from transiently becoming available for > scheduling when being onlined at runtime? This looks like an argument for cancelling at call-in time, no? > --- 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) > > `= ` > > +### ht (x86) I'd suggest smt rather than ht here. SMT is the technical term, while HT is Intel's marketing name. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
