From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>,
Brian Woods <brian.woods@amd.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH 5/9] x86/amd: Probe for legacy SSBD interfaces on boot
Date: Fri, 04 Jan 2019 01:58:48 -0700 [thread overview]
Message-ID: <5C2F2048020000780020A1EC@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <a43b8a78-5bda-6f85-549f-135355a1e7de@citrix.com>
>>> On 28.12.18 at 17:30, <andrew.cooper3@citrix.com> wrote:
> On 06/12/2018 10:59, Jan Beulich wrote:
>>>>> On 03.12.18 at 17:18, <andrew.cooper3@citrix.com> wrote:
>>> --- a/xen/include/asm-x86/cpufeatures.h
>>> +++ b/xen/include/asm-x86/cpufeatures.h
>>> @@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP, (FSCAPINTS+0)*32+11) /*
> SMAP gets used by Xen it
>>> XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as
> Dispatch Serialising */
>>> XEN_CPUFEATURE(IND_THUNK_LFENCE,(FSCAPINTS+0)*32+13) /* Use
> IND_THUNK_LFENCE */
>>> XEN_CPUFEATURE(IND_THUNK_JMP, (FSCAPINTS+0)*32+14) /* Use IND_THUNK_JMP
> */
>>> +XEN_CPUFEATURE(LEGACY_SSBD, (FSCAPINTS+0)*32+15) /* LS_CFG or
> VIRT_SPEC_CTRL available for SSBD */
>> As already indicated in another reply, with there not being
>> any alternatives patching based on this, I don't think it should
>> be a synthetic feature. Use an ordinary bool variable instead.
>
> What makes you believe that synthetic bits are only for livepatching?
> Less than half of the existing ones are used for that purpose, and its
> not how Linux treats them.
>
> They are a collection of misc unsorted feature bits, and that's exactly
> what I'm using it for here.
I'm convinced the introduction of synthetic bits in Linux was
for the purpose of alternatives patching, as anything else can
be expressed using ordinary variables. Even if Linux later went
and abused the construct, I don't think we should follow that
model; I'd actually aim at removing synthetic features which
aren't used for alternatives patching, as you can see from e.g.
56e619b4d3 ("x86: drop NO_XPTI synthetic feature").
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-01-04 8:58 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 16:18 [PATCH 0/9] xen/amd: Support for guest MSR_VIRT_SPEC_CTRL support Andrew Cooper
2018-12-03 16:18 ` [PATCH 1/9] x86/spec-ctrl: Drop the bti= command line option Andrew Cooper
2018-12-04 16:19 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 2/9] x86/cpuid: Drop the synthetic X86_FEATURE_XEN_IBPB Andrew Cooper
2018-12-04 16:21 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 3/9] x86/cpuid: Extend the cpuid= command line option to support all named features Andrew Cooper
2018-12-04 16:28 ` Jan Beulich
2018-12-06 12:52 ` Wei Liu
2018-12-03 16:18 ` [PATCH 4/9] x86/amd: Introduce CPUID/MSR definitions for per-vcpu SSBD support Andrew Cooper
2018-12-04 16:06 ` Woods, Brian
2018-12-05 16:39 ` Jan Beulich
2018-12-05 17:50 ` Andrew Cooper
2018-12-06 8:49 ` Jan Beulich
2018-12-06 18:35 ` Andrew Cooper
2018-12-03 16:18 ` [PATCH 5/9] x86/amd: Probe for legacy SSBD interfaces on boot Andrew Cooper
2018-12-04 16:15 ` Woods, Brian
2018-12-05 16:50 ` Jan Beulich
2018-12-05 17:09 ` Andrew Cooper
2018-12-06 8:53 ` Jan Beulich
2018-12-06 10:59 ` Jan Beulich
2018-12-28 16:30 ` Andrew Cooper
2019-01-04 8:58 ` Jan Beulich [this message]
2018-12-03 16:18 ` [PATCH 6/9] x86/amd: Allocate resources to cope with LS_CFG being per-core on Fam17h Andrew Cooper
2018-12-04 16:38 ` Woods, Brian
2018-12-05 16:57 ` Jan Beulich
2018-12-05 17:05 ` Andrew Cooper
2018-12-06 8:54 ` Jan Beulich
2018-12-06 18:46 ` Andrew Cooper
2018-12-06 19:25 ` Woods, Brian
2018-12-07 10:17 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 7/9] x86/amd: Support context switching legacy SSBD interface Andrew Cooper
2018-12-04 20:27 ` Woods, Brian
2018-12-06 10:51 ` Jan Beulich
2018-12-06 18:55 ` Andrew Cooper
2018-12-07 10:25 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 8/9] x86/amd: Virtualise MSR_VIRT_SPEC_CTRL for guests Andrew Cooper
2018-12-04 21:35 ` Woods, Brian
2018-12-05 8:41 ` Jan Beulich
2018-12-05 19:09 ` Andrew Cooper
2018-12-06 8:59 ` Jan Beulich
2018-12-06 19:41 ` Woods, Brian
2018-12-06 10:55 ` Jan Beulich
2018-12-03 16:18 ` [PATCH 9/9] x86/amd: Offer MSR_VIRT_SPEC_CTRL to guests Andrew Cooper
2018-12-06 10:57 ` Jan Beulich
2018-12-03 16:24 ` [PATCH 0/9] xen/amd: Support for guest MSR_VIRT_SPEC_CTRL support Jan Beulich
2018-12-03 16:31 ` Andrew Cooper
2018-12-04 9:45 ` Jan Beulich
2018-12-04 11:26 ` Andrew Cooper
2018-12-04 12:45 ` Jan Beulich
2018-12-04 13:41 ` Andrew Cooper
2018-12-04 14:07 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5C2F2048020000780020A1EC@prv1-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=brian.woods@amd.com \
--cc=roger.pau@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).