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