How about...
static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT,
How about...
static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT,
On Wed, 2018-01-24 at 18:40 +, Alan Cox wrote:
> Nobody has published official statements on Cyrix or AMD 32bit processors
> so we don't know if they are vulnerable to meltdown. One problem I
> suspect is that as with things like Alpha 21264 - the people who knew are
> probably long retired.
On Wed, 2018-01-24 at 18:40 +, Alan Cox wrote:
> Nobody has published official statements on Cyrix or AMD 32bit processors
> so we don't know if they are vulnerable to meltdown. One problem I
> suspect is that as with things like Alpha 21264 - the people who knew are
> probably long retired.
> > AND K5 speculates, Cyrix 6x86 speculates, IDT WinChip does not. I think
> > this should be
> >
> > X86_VENDOR_ANY, 4
> > X86_VENDOR_INTEL, 5,
> > X86_VENDOR_CENTAUR, 5,
>
> Hm, for the specific case of controlling X86_BUG_CPU_MELTDOWN it's not
> just "speculates" which is the criterion.
> > AND K5 speculates, Cyrix 6x86 speculates, IDT WinChip does not. I think
> > this should be
> >
> > X86_VENDOR_ANY, 4
> > X86_VENDOR_INTEL, 5,
> > X86_VENDOR_CENTAUR, 5,
>
> Hm, for the specific case of controlling X86_BUG_CPU_MELTDOWN it's not
> just "speculates" which is the criterion.
On Wed, 2018-01-24 at 17:07 +, Alan Cox wrote:
> >
> >
> > +static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
> > + { X86_VENDOR_AMD },
> > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
> > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW,
On Wed, 2018-01-24 at 17:07 +, Alan Cox wrote:
> >
> >
> > +static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
> > + { X86_VENDOR_AMD },
> > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
> > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW,
>
> +static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
> + { X86_VENDOR_AMD },
> + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
> + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
> + { X86_VENDOR_INTEL, 6,
>
> +static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
> + { X86_VENDOR_AMD },
> + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
> + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
> + { X86_VENDOR_INTEL, 6,
On Tue, 2018-01-23 at 18:45 +, Alan Cox wrote:
> On Tue, 23 Jan 2018 16:52:55 +
> David Woodhouse wrote:
>
> >
> > When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> > bit set, they don't need KPTI either.
> This is starting to get messy
On Tue, 2018-01-23 at 18:45 +, Alan Cox wrote:
> On Tue, 23 Jan 2018 16:52:55 +
> David Woodhouse wrote:
>
> >
> > When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> > bit set, they don't need KPTI either.
> This is starting to get messy because we will
On Tue, 2018-01-23 at 10:40 -0800, Dave Hansen wrote:
>
> I'd really rather we break this out into a nice, linear set of
> true/false conditions.
>
> bool early_cpu_vulnerable_meltdown(struct cpuinfo_x86 *c)
> {
> u64 ia32_cap = 0;
>
> /* AMD processors are not subject to
On Tue, 2018-01-23 at 10:40 -0800, Dave Hansen wrote:
>
> I'd really rather we break this out into a nice, linear set of
> true/false conditions.
>
> bool early_cpu_vulnerable_meltdown(struct cpuinfo_x86 *c)
> {
> u64 ia32_cap = 0;
>
> /* AMD processors are not subject to
On Tue, 2018-01-23 at 10:12 -0800, Andi Kleen wrote:
> > - if (c->x86_vendor != X86_VENDOR_AMD)
> > - setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);
> > + if (c->x86_vendor != X86_VENDOR_AMD) {
> > + u64 ia32_cap = 0;
> > +
> > + if (cpu_has(c,
On Tue, 2018-01-23 at 10:12 -0800, Andi Kleen wrote:
> > - if (c->x86_vendor != X86_VENDOR_AMD)
> > - setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);
> > + if (c->x86_vendor != X86_VENDOR_AMD) {
> > + u64 ia32_cap = 0;
> > +
> > + if (cpu_has(c,
> On Tue, 2018-01-23 at 18:45 +, Alan Cox wrote:
>
> static __initdata struct x86_cpu_id cpu_in_order[] = {
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
> {
> On Tue, 2018-01-23 at 18:45 +, Alan Cox wrote:
>
> static __initdata struct x86_cpu_id cpu_in_order[] = {
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
> {
> > static int in_order_cpu(void)
> > {
> > /* Processors with CPU id etc */
> > if (x86_match_cpu(cpu_in_order))
> > return 1;
> > /* Other rules here */
> > return 0;
> > }
>
> Why does in-order vs out-of-order matter?
>
> There are leaky SP3 gadgets which satisfy
> > static int in_order_cpu(void)
> > {
> > /* Processors with CPU id etc */
> > if (x86_match_cpu(cpu_in_order))
> > return 1;
> > /* Other rules here */
> > return 0;
> > }
>
> Why does in-order vs out-of-order matter?
>
> There are leaky SP3 gadgets which satisfy
On Tue, Jan 23, 2018 at 10:45 AM, Alan Cox wrote:
>
> static int in_order_cpu(void)
> {
> /* Processors with CPU id etc */
> if (x86_match_cpu(cpu_in_order))
> return 1;
> /* Other rules here */
> return 0;
> }
Note that
On Tue, Jan 23, 2018 at 10:45 AM, Alan Cox wrote:
>
> static int in_order_cpu(void)
> {
> /* Processors with CPU id etc */
> if (x86_match_cpu(cpu_in_order))
> return 1;
> /* Other rules here */
> return 0;
> }
Note that "in-order" does *not*
On 23/01/18 18:45, Alan Cox wrote:
> On Tue, 23 Jan 2018 16:52:55 +
> David Woodhouse wrote:
>
>> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
>> bit set, they don't need KPTI either.
> This is starting to get messy because we will eventually
On 23/01/18 18:45, Alan Cox wrote:
> On Tue, 23 Jan 2018 16:52:55 +
> David Woodhouse wrote:
>
>> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
>> bit set, they don't need KPTI either.
> This is starting to get messy because we will eventually need to integrate
>
>
On Tue, 2018-01-23 at 10:41 -0800, Dave Hansen wrote:
> On 01/23/2018 08:52 AM, David Woodhouse wrote:
> > When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> > bit set, they don't need KPTI either.
>
> Also, I hate to ask... Have you tested this patch?
Nope. I
On Tue, 2018-01-23 at 10:41 -0800, Dave Hansen wrote:
> On 01/23/2018 08:52 AM, David Woodhouse wrote:
> > When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> > bit set, they don't need KPTI either.
>
> Also, I hate to ask... Have you tested this patch?
Nope. I
On Tue, 23 Jan 2018 16:52:55 +
David Woodhouse wrote:
> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> bit set, they don't need KPTI either.
This is starting to get messy because we will eventually need to integrate
AMD processors -
On Tue, 23 Jan 2018 16:52:55 +
David Woodhouse wrote:
> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> bit set, they don't need KPTI either.
This is starting to get messy because we will eventually need to integrate
AMD processors - no meltdown
On 01/23/2018 08:52 AM, David Woodhouse wrote:
> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> bit set, they don't need KPTI either.
Also, I hate to ask... Have you tested this patch?
On 01/23/2018 08:52 AM, David Woodhouse wrote:
> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> bit set, they don't need KPTI either.
Also, I hate to ask... Have you tested this patch?
On 01/23/2018 08:52 AM, David Woodhouse wrote:
> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> bit set, they don't need KPTI either.
>
> Signed-off-by: David Woodhouse
> ---
> arch/x86/kernel/cpu/common.c | 10 --
> 1 file changed, 8
On 01/23/2018 08:52 AM, David Woodhouse wrote:
> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> bit set, they don't need KPTI either.
>
> Signed-off-by: David Woodhouse
> ---
> arch/x86/kernel/cpu/common.c | 10 --
> 1 file changed, 8 insertions(+), 2
>
> - if (c->x86_vendor != X86_VENDOR_AMD)
> - setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);
> + if (c->x86_vendor != X86_VENDOR_AMD) {
> + u64 ia32_cap = 0;
> +
> + if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
> +
>
> - if (c->x86_vendor != X86_VENDOR_AMD)
> - setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);
> + if (c->x86_vendor != X86_VENDOR_AMD) {
> + u64 ia32_cap = 0;
> +
> + if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
> +
34 matches
Mail list logo