On Tue, 30 Jan 2018, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote:
> > So much for the theory. That's not going to work. If the boot cpu has the
> > feature then the alternatives will have been applied. So even if the flag
> > mismatch can be observed whe
On Tue, 2018-01-30 at 14:54 +, Alan Cox wrote:
> The only case I can think of where you'd get a non boot processor that
> didn't have the same microcode loaded as the rest on entry to the OS would
> be in a system where it was possibly to phyically hot plug processors
> post boot.
>
> There
On Tue, 30 Jan 2018 06:01:43 -0800
Arjan van de Ven wrote:
> On 1/30/2018 5:11 AM, Borislav Petkov wrote:
> > On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote:
> >> So much for the theory. That's not going to work. If the boot cpu has the
> >> feature then the alternatives will h
On 1/30/2018 5:11 AM, Borislav Petkov wrote:
On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote:
So much for the theory. That's not going to work. If the boot cpu has the
feature then the alternatives will have been applied. So even if the flag
mismatch can be observed when a second
On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote:
> So much for the theory. That's not going to work. If the boot cpu has the
> feature then the alternatives will have been applied. So even if the flag
> mismatch can be observed when a secondary CPU comes up the outcome will be
> acc
On Tue, 30 Jan 2018, David Woodhouse wrote:
> On Tue, 2018-01-30 at 12:37 +0100, Thomas Gleixner wrote:
>
> > In any case, if there is ucode mismatch between CPUs the whole thing is
> > hosed anyway no matter what. So can you please agree on a solution so we
> > can unbreak the current state of a
On Tue, 2018-01-30 at 12:37 +0100, Thomas Gleixner wrote:
> In any case, if there is ucode mismatch between CPUs the whole thing is
> hosed anyway no matter what. So can you please agree on a solution so we
> can unbreak the current state of affairs?
If there is µcode mismatch between CPUs then t
On Tue, 30 Jan 2018, David Woodhouse wrote:
> On Tue, 2018-01-30 at 12:18 +0100, Borislav Petkov wrote:
> > On Tue, Jan 30, 2018 at 11:03:50AM +, David Woodhouse wrote:
> > >
> > > I pondered that, but I didn't like it. I didn't want to always *force*
> > > those features on, for all CPUs, jus
On Tue, 2018-01-30 at 12:18 +0100, Borislav Petkov wrote:
> On Tue, Jan 30, 2018 at 11:03:50AM +, David Woodhouse wrote:
> >
> > I pondered that, but I didn't like it. I didn't want to always *force*
> > those features on, for all CPUs, just because they happened to be
> > discovered at boot
On Tue, Jan 30, 2018 at 11:03:50AM +, David Woodhouse wrote:
> I pondered that, but I didn't like it. I didn't want to always *force*
> those features on, for all CPUs, just because they happened to be
> discovered at boot time on the first CPU (which *did* have its
> microcode updated by the c
On Tue, 2018-01-30 at 11:58 +0100, Borislav Petkov wrote:
>
> Does that help?
>
> diff --git a/arch/x86/kernel/cpu/intel.c
> b/arch/x86/kernel/cpu/intel.c
> index 6936d14d4c77..1dd596d0a6c4 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -182,21 +182,21 @@ stat
On Mon, Jan 29, 2018 at 11:49:33PM +, David Woodhouse wrote:
> Despite the fact that all the other code there seems to be doing it,
> just using set_cpu_cap() in early_intel_init() doesn't actually work.
>
> When the CPU is queried again in identify_boot_cpu(), it all gets
> overwritten again.
On Mon, 29 Jan 2018, David Woodhouse wrote:
> Despite the fact that all the other code there seems to be doing it,
> just using set_cpu_cap() in early_intel_init() doesn't actually work.
>
> When the CPU is queried again in identify_boot_cpu(), it all gets
> overwritten again. Do it in init_scatt
Despite the fact that all the other code there seems to be doing it,
just using set_cpu_cap() in early_intel_init() doesn't actually work.
When the CPU is queried again in identify_boot_cpu(), it all gets
overwritten again. Do it in init_scattered_cpuid_features() instead.
Turning the bits off fo
14 matches
Mail list logo
