On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> > I'm filling a bug on Debian glibc, asking them to blacklist HLE until
> > further notice.
>
> FWIW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
Also, glibc lock
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
I'm filling a bug on Debian glibc, asking them to blacklist HLE until
further notice.
FWIW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
Also, glibc lock elision
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 01:41:21PM -0300, Henrique de Moraes Holschuh wrote:
> > We still need to update x86_capability after a microcode update for the
> > above to really work in the "install microcode into initramfs" case.
>
> I think you mean for
On Thu, Sep 25, 2014 at 01:41:21PM -0300, Henrique de Moraes Holschuh wrote:
> We still need to update x86_capability after a microcode update for the
> above to really work in the "install microcode into initramfs" case.
I think you mean for the kernels without early microcode loading...
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 12:30:06PM -0300, Henrique de Moraes Holschuh wrote:
> > Userspace can install the microcode only inside the initramfs, if it wants
> > to avoid it being loaded later. It is not even too difficult to do so.
>
> Hmm, so in
On Thu, Sep 25, 2014 at 12:30:06PM -0300, Henrique de Moraes Holschuh wrote:
> Userspace can install the microcode only inside the initramfs, if it wants
> to avoid it being loaded later. It is not even too difficult to do so.
Hmm, so in thinking about this more, what we need to do on all
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 11:40:25AM -0300, Henrique de Moraes Holschuh wrote:
> > At this point, what alternatives are left?
>
> Here's what we could do:
>
> * Install microcode to /lib/firmware/...
>
> * Refuse to update the microcode and tell the
On Thu, Sep 25, 2014 at 11:40:25AM -0300, Henrique de Moraes Holschuh wrote:
> At this point, what alternatives are left?
Here's what we could do:
* Install microcode to /lib/firmware/...
* Refuse to update the microcode and tell the user that she needs to reboot.
* Reboot and load the
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 08:36:45AM -0300, Henrique de Moraes Holschuh wrote:
> > This isn't an useless fix, it will allow systems without early initramfs
> > support to operate correctly after a microcode update.
>
> So what do we do if we update the
On Thu, Sep 25, 2014 at 08:36:45AM -0300, Henrique de Moraes Holschuh wrote:
> This isn't an useless fix, it will allow systems without early initramfs
> support to operate correctly after a microcode update.
So what do we do if we update the microcode late and some userspace task
is using HLE
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> > But IMHO we still need to detect and do something smart when
> > x86_capability changes due to a microcode update.
> >
> > And I'd really prefer it to be "update x86_capability, warn the user and
> > carry on" for anything that is not going to crash
On Wed, Sep 24, 2014 at 02:45:57PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 24 Sep 2014, Andy Lutomirski wrote:
> > On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
> > wrote:
> > > And I'd really prefer it to be "update x86_capability, warn the user and
> > > carry on" for
On Wed, Sep 24, 2014 at 11:56:58AM -0300, Henrique de Moraes Holschuh wrote:
> I don't know about AMD, but on Intel, the time it takes to update the
> microcode on a core is anything but negligible[1], so the microcode
> version skew window still exists, and it is not small. It is much smaller
>
On Wed, Sep 24, 2014 at 11:56:58AM -0300, Henrique de Moraes Holschuh wrote:
I don't know about AMD, but on Intel, the time it takes to update the
microcode on a core is anything but negligible[1], so the microcode
version skew window still exists, and it is not small. It is much smaller
than
On Wed, Sep 24, 2014 at 02:45:57PM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
h...@hmh.eng.br wrote:
And I'd really prefer it to be update x86_capability, warn the user and
carry on
On Thu, 25 Sep 2014, Borislav Petkov wrote:
But IMHO we still need to detect and do something smart when
x86_capability changes due to a microcode update.
And I'd really prefer it to be update x86_capability, warn the user and
carry on for anything that is not going to crash the kernel.
On Thu, Sep 25, 2014 at 08:36:45AM -0300, Henrique de Moraes Holschuh wrote:
This isn't an useless fix, it will allow systems without early initramfs
support to operate correctly after a microcode update.
So what do we do if we update the microcode late and some userspace task
is using HLE and
On Thu, 25 Sep 2014, Borislav Petkov wrote:
On Thu, Sep 25, 2014 at 08:36:45AM -0300, Henrique de Moraes Holschuh wrote:
This isn't an useless fix, it will allow systems without early initramfs
support to operate correctly after a microcode update.
So what do we do if we update the
On Thu, Sep 25, 2014 at 11:40:25AM -0300, Henrique de Moraes Holschuh wrote:
At this point, what alternatives are left?
Here's what we could do:
* Install microcode to /lib/firmware/...
* Refuse to update the microcode and tell the user that she needs to reboot.
* Reboot and load the
On Thu, 25 Sep 2014, Borislav Petkov wrote:
On Thu, Sep 25, 2014 at 11:40:25AM -0300, Henrique de Moraes Holschuh wrote:
At this point, what alternatives are left?
Here's what we could do:
* Install microcode to /lib/firmware/...
* Refuse to update the microcode and tell the user that
On Thu, Sep 25, 2014 at 12:30:06PM -0300, Henrique de Moraes Holschuh wrote:
Userspace can install the microcode only inside the initramfs, if it wants
to avoid it being loaded later. It is not even too difficult to do so.
Hmm, so in thinking about this more, what we need to do on all kernels
On Thu, 25 Sep 2014, Borislav Petkov wrote:
On Thu, Sep 25, 2014 at 12:30:06PM -0300, Henrique de Moraes Holschuh wrote:
Userspace can install the microcode only inside the initramfs, if it wants
to avoid it being loaded later. It is not even too difficult to do so.
Hmm, so in thinking
On Thu, Sep 25, 2014 at 01:41:21PM -0300, Henrique de Moraes Holschuh wrote:
We still need to update x86_capability after a microcode update for the
above to really work in the install microcode into initramfs case.
I think you mean for the kernels without early microcode loading...
Because
On Thu, 25 Sep 2014, Borislav Petkov wrote:
On Thu, Sep 25, 2014 at 01:41:21PM -0300, Henrique de Moraes Holschuh wrote:
We still need to update x86_capability after a microcode update for the
above to really work in the install microcode into initramfs case.
I think you mean for the
On Wed, Sep 24, 2014 at 11:59 AM, Henrique de Moraes Holschuh
wrote:
> On Wed, 24 Sep 2014, Andy Lutomirski wrote:
>> We can sort of fudge it if whatever control BIOS uses is available to
>> us, too, and we can reprogram it to "enabled" after a microcode update
>> disables TSX.
>
> Only for the
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
> We can sort of fudge it if whatever control BIOS uses is available to
> us, too, and we can reprogram it to "enabled" after a microcode update
> disables TSX.
Only for the early initramfs microcode update driver, and that's going to be
useful only as
On Wed, Sep 24, 2014 at 10:45 AM, Henrique de Moraes Holschuh
wrote:
> On Wed, 24 Sep 2014, Andy Lutomirski wrote:
>> On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
>> wrote:
>> > And I'd really prefer it to be "update x86_capability, warn the user and
>> > carry on" for anything
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
> On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
> wrote:
> > And I'd really prefer it to be "update x86_capability, warn the user and
> > carry on" for anything that is not going to crash the kernel. Several
> > distros will really want
On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
wrote:
> On Tue, 23 Sep 2014, Borislav Petkov wrote:
>> On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
>> > 1. offline a "guinea pig" group of "cpus", i.e. an entire "microcode update
>> > unit" that
On Tue, 23 Sep 2014, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
> > 1. offline a "guinea pig" group of "cpus", i.e. an entire "microcode update
> > unit" that doesn't include the BSP. This is going to be a pain, as what
> > composes a
On Tue, 23 Sep 2014, Borislav Petkov wrote:
On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
1. offline a guinea pig group of cpus, i.e. an entire microcode update
unit that doesn't include the BSP. This is going to be a pain, as what
composes a microcode update
On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
h...@hmh.eng.br wrote:
On Tue, 23 Sep 2014, Borislav Petkov wrote:
On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
1. offline a guinea pig group of cpus, i.e. an entire microcode update
unit that
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
h...@hmh.eng.br wrote:
And I'd really prefer it to be update x86_capability, warn the user and
carry on for anything that is not going to crash the kernel. Several
distros will really
On Wed, Sep 24, 2014 at 10:45 AM, Henrique de Moraes Holschuh
h...@hmh.eng.br wrote:
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
h...@hmh.eng.br wrote:
And I'd really prefer it to be update x86_capability, warn the user and
carry
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
We can sort of fudge it if whatever control BIOS uses is available to
us, too, and we can reprogram it to enabled after a microcode update
disables TSX.
Only for the early initramfs microcode update driver, and that's going to be
useful only as a way
On Wed, Sep 24, 2014 at 11:59 AM, Henrique de Moraes Holschuh
h...@hmh.eng.br wrote:
On Wed, 24 Sep 2014, Andy Lutomirski wrote:
We can sort of fudge it if whatever control BIOS uses is available to
us, too, and we can reprogram it to enabled after a microcode update
disables TSX.
Only for
On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
> 1. offline a "guinea pig" group of "cpus", i.e. an entire "microcode update
> unit" that doesn't include the BSP. This is going to be a pain, as what
> composes a "microcode update unit" is not set in stone, and could
On Fri, Sep 19, 2014 at 01:42:17PM -0300, Henrique de Moraes Holschuh wrote:
1. offline a guinea pig group of cpus, i.e. an entire microcode update
unit that doesn't include the BSP. This is going to be a pain, as what
composes a microcode update unit is not set in stone, and could change in
On Sun, Sep 21, 2014 at 05:51:12PM -0700, H. Peter Anvin wrote:
> He said *outside* of the early update mechanism.
True. Sorry yes I misread it.
Yes, that's the way to go.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
He said *outside* of the early update mechanism.
On September 21, 2014 5:37:24 PM PDT, Andi Kleen wrote:
>Henrique de Moraes Holschuh writes:
>
>
>> And yes, this means we will kill support for microcode updates
>> outside of the initramfs/early-initramfs, at least in Debian,
>> and
Henrique de Moraes Holschuh writes:
> And yes, this means we will kill support for microcode updates
> outside of the initramfs/early-initramfs, at least in Debian,
> and likely in Ubuntu.
You got it totally backwards. initramfs updating should handle this
microcode update just
Henrique de Moraes Holschuh h...@hmh.eng.br writes:
And yes, this means we will kill support for microcode updates
outside of the initramfs/early-initramfs, at least in Debian,
and likely in Ubuntu.
You got it totally backwards. initramfs updating should handle this
microcode
He said *outside* of the early update mechanism.
On September 21, 2014 5:37:24 PM PDT, Andi Kleen a...@firstfloor.org wrote:
Henrique de Moraes Holschuh h...@hmh.eng.br writes:
And yes, this means we will kill support for microcode updates
outside of the initramfs/early-initramfs, at
On Sun, Sep 21, 2014 at 05:51:12PM -0700, H. Peter Anvin wrote:
He said *outside* of the early update mechanism.
True. Sorry yes I misread it.
Yes, that's the way to go.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> I'm filling a bug on Debian glibc, asking them to blacklist HLE until
> further notice.
FWIW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
--
"One disk to rule them all, One disk to find them. One disk to bring
them all
On Fri, 19 Sep 2014, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 10:51:08AM -0300, Henrique de Moraes Holschuh wrote:
> > But I will not trigger a microcode update when the intel-microcode package
> > gets updated/installed anymore. The user will be warned of the need for
> > either a reboot
On Fri, 19 Sep 2014, Andy Lutomirski wrote:
> Can we change the ucode blob format for these firmwares so that old
> kernels won't apply them? I have no other good ideas. The trouble is
> that distros *should* push out the new ucode, but only if there's some
> guarantee that they'll only be
On Fri, 19 Sep 2014, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
> > 2) Don't allow a late update if TSX is still enabled on those
> > processors.
>
> Yeah, so the use case I have in mind is when a long-running machine
> wants to apply microcode and this
On Fri, Sep 19, 2014 at 8:00 AM, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
>> Assuming we can identify all the affected models and steppings, maybe
>> something like this would work:
>>
>> 1) Refuse to finish booting if a microcode update that disables
On Thu, 18 Sep 2014, Andy Lutomirski wrote:
> > [2] instantly segfaulting every running process using libpthread-2.19,
> > as well as any other users of Intel TSX.
> > https://bugs.launchpad.net/intel/+bug/1370352
> >
> > And yes, this means we will kill support for microcode updates
On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
> Assuming we can identify all the affected models and steppings, maybe
> something like this would work:
>
> 1) Refuse to finish booting if a microcode update that disables TSX
> isn't applied before userspace starts running on those
On Fri, Sep 19, 2014 at 10:51:08AM -0300, Henrique de Moraes Holschuh wrote:
> And I will also continue to pester you with patches to the microcode driver
> :-)
That's fine - I'm currently busy and not looking at them but I haven't
forgotten them.
> But I will not trigger a microcode update when
On Fri, 19 Sep 2014, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
> > We're also killing microcode update support outside of the initramfs in
> > Debian. It has become obvious that anything other than the early initramfs
> > method of
On Fri, 19 Sep 2014 09:14:50 -0400
Josh Boyer wrote:
> On Fri, Sep 19, 2014 at 8:54 AM, Chuck Ebbert wrote:
> > On Fri, 19 Sep 2014 13:29:53 +0200
> > Borislav Petkov wrote:
> >
> >> On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh
> >> wrote:
> >> > We're also killing
On Fri, Sep 19, 2014 at 8:54 AM, Chuck Ebbert wrote:
> On Fri, 19 Sep 2014 13:29:53 +0200
> Borislav Petkov wrote:
>
>> On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
>> > We're also killing microcode update support outside of the initramfs in
>> > Debian. It has
On Fri, 19 Sep 2014 13:29:53 +0200
Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
> > We're also killing microcode update support outside of the initramfs in
> > Debian. It has become obvious that anything other than the early initramfs
> >
On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
> We're also killing microcode update support outside of the initramfs in
> Debian. It has become obvious that anything other than the early initramfs
> method of microcode updates should be considered a developer thing.
On Thu, 18 Sep 2014, Andy Lutomirski wrote:
> On Sep 18, 2014 5:13 PM, "Henrique de Moraes Holschuh"
> wrote:
> > Here's a plan that might work, pending actually checking the libpthread TSX
> > code to make sure it keys on /proc/cpuinfo flags:
>
> Surely it checks cpuid directly, though.
On Thu, 18 Sep 2014, Chuck Ebbert wrote:
> > > [1] sig 0x000306f2, pf mask 0x6f, 2014-09-03, rev 0x0029, size 28672
> > > sig 0x000306c3, pf mask 0x32, 2014-07-03, rev 0x001c, size 21504
> > > sig 0x00040651, pf mask 0x72, 2014-07-03, rev 0x001c, size 20480
> > > sig 0x00040661, pf
On Thu, Sep 18, 2014 at 06:00:12PM -0700, Andy Lutomirski wrote:
> Yes, but how? I assume that BIOS isn't switching between two
> different ucode blobs, and I don't know about any wrcpuid instruction.
> So there must be *some* way, at least on new ucode (and maybe on old
> ucode) to change that
On Thu, Sep 18, 2014 at 06:00:12PM -0700, Andy Lutomirski wrote:
Yes, but how? I assume that BIOS isn't switching between two
different ucode blobs, and I don't know about any wrcpuid instruction.
So there must be *some* way, at least on new ucode (and maybe on old
ucode) to change that bit.
On Thu, 18 Sep 2014, Chuck Ebbert wrote:
[1] sig 0x000306f2, pf mask 0x6f, 2014-09-03, rev 0x0029, size 28672
sig 0x000306c3, pf mask 0x32, 2014-07-03, rev 0x001c, size 21504
sig 0x00040651, pf mask 0x72, 2014-07-03, rev 0x001c, size 20480
sig 0x00040661, pf mask 0x32,
On Thu, 18 Sep 2014, Andy Lutomirski wrote:
On Sep 18, 2014 5:13 PM, Henrique de Moraes Holschuh h...@hmh.eng.br
wrote:
Here's a plan that might work, pending actually checking the libpthread TSX
code to make sure it keys on /proc/cpuinfo flags:
Surely it checks cpuid directly, though.
On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
We're also killing microcode update support outside of the initramfs in
Debian. It has become obvious that anything other than the early initramfs
method of microcode updates should be considered a developer thing.
On Fri, 19 Sep 2014 13:29:53 +0200
Borislav Petkov b...@alien8.de wrote:
On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
We're also killing microcode update support outside of the initramfs in
Debian. It has become obvious that anything other than the early
On Fri, Sep 19, 2014 at 8:54 AM, Chuck Ebbert cebbert.l...@gmail.com wrote:
On Fri, 19 Sep 2014 13:29:53 +0200
Borislav Petkov b...@alien8.de wrote:
On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
We're also killing microcode update support outside of the
On Fri, 19 Sep 2014 09:14:50 -0400
Josh Boyer jwbo...@fedoraproject.org wrote:
On Fri, Sep 19, 2014 at 8:54 AM, Chuck Ebbert cebbert.l...@gmail.com wrote:
On Fri, 19 Sep 2014 13:29:53 +0200
Borislav Petkov b...@alien8.de wrote:
On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes
On Fri, 19 Sep 2014, Borislav Petkov wrote:
On Fri, Sep 19, 2014 at 08:00:15AM -0300, Henrique de Moraes Holschuh wrote:
We're also killing microcode update support outside of the initramfs in
Debian. It has become obvious that anything other than the early initramfs
method of microcode
On Fri, Sep 19, 2014 at 10:51:08AM -0300, Henrique de Moraes Holschuh wrote:
And I will also continue to pester you with patches to the microcode driver
:-)
That's fine - I'm currently busy and not looking at them but I haven't
forgotten them.
But I will not trigger a microcode update when
On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
Assuming we can identify all the affected models and steppings, maybe
something like this would work:
1) Refuse to finish booting if a microcode update that disables TSX
isn't applied before userspace starts running on those CPUs.
On Thu, 18 Sep 2014, Andy Lutomirski wrote:
[2] instantly segfaulting every running process using libpthread-2.19,
as well as any other users of Intel TSX.
https://bugs.launchpad.net/intel/+bug/1370352
And yes, this means we will kill support for microcode updates
On Fri, Sep 19, 2014 at 8:00 AM, Borislav Petkov b...@alien8.de wrote:
On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
Assuming we can identify all the affected models and steppings, maybe
something like this would work:
1) Refuse to finish booting if a microcode update that
On Fri, 19 Sep 2014, Borislav Petkov wrote:
On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote:
2) Don't allow a late update if TSX is still enabled on those
processors.
Yeah, so the use case I have in mind is when a long-running machine
wants to apply microcode and this
On Fri, 19 Sep 2014, Andy Lutomirski wrote:
Can we change the ucode blob format for these firmwares so that old
kernels won't apply them? I have no other good ideas. The trouble is
that distros *should* push out the new ucode, but only if there's some
guarantee that they'll only be applied
On Fri, 19 Sep 2014, Borislav Petkov wrote:
On Fri, Sep 19, 2014 at 10:51:08AM -0300, Henrique de Moraes Holschuh wrote:
But I will not trigger a microcode update when the intel-microcode package
gets updated/installed anymore. The user will be warned of the need for
either a reboot or a
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
I'm filling a bug on Debian glibc, asking them to blacklist HLE until
further notice.
FWIW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
--
One disk to rule them all, One disk to find them. One disk to bring
them all and
On Sep 18, 2014 5:28 PM, "H. Peter Anvin" wrote:
>
> The cpuid bit gets twiddled...
Yes, but how? I assume that BIOS isn't switching between two
different ucode blobs, and I don't know about any wrcpuid instruction.
So there must be *some* way, at least on new ucode (and maybe on old
ucode) to
The cpuid bit gets twiddled...
On September 18, 2014 5:23:40 PM PDT, Andy Lutomirski
wrote:
>On Sep 18, 2014 5:13 PM, "Henrique de Moraes Holschuh"
>wrote:
>>
>> On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
>> > On Thu, 18 Sep 2014, H. Peter Anvin wrote:
>> > > We should, but this
On Sep 18, 2014 5:13 PM, "Henrique de Moraes Holschuh" wrote:
>
> On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
> > On Thu, 18 Sep 2014, H. Peter Anvin wrote:
> > > We should, but this is also part of why we want the early ucode
> > > capability.
> >
> > Well, yes. But that won't help
On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
> On Thu, 18 Sep 2014, H. Peter Anvin wrote:
> > We should, but this is also part of why we want the early ucode capability.
>
> Well, yes. But that won't help the several stable and LTS distros with
> kernels without early ucode update
On Thu, 18 Sep 2014, H. Peter Anvin wrote:
> We should, but this is also part of why we want the early ucode capability.
Well, yes. But that won't help the several stable and LTS distros with
kernels without early ucode update support.
--
"One disk to rule them all, One disk to find them.
On Thu, 18 Sep 2014 12:14:59 -0700
Andy Lutomirski wrote:
> On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
> > The new Haswell microcode update[1] removes the "hle" (hardware lock
> > elision) processor capability. And it is not cosmetic, either: Intel TSX
> > opcodes will cause an
We should, but this is also part of why we want the early ucode capability.
On September 18, 2014 12:53:28 PM PDT, Chuck Ebbert
wrote:
>On Thu, 18 Sep 2014 12:14:59 -0700
>Andy Lutomirski wrote:
>
>> On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
>> > The new Haswell microcode
On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
> The new Haswell microcode update[1] removes the "hle" (hardware lock
> elision) processor capability. And it is not cosmetic, either: Intel TSX
> opcodes will cause an illegal opcode trap after the microcode update[2].
>
> This means
The new Haswell microcode update[1] removes the "hle" (hardware lock
elision) processor capability. And it is not cosmetic, either: Intel TSX
opcodes will cause an illegal opcode trap after the microcode update[2].
This means cpu_info()->x86_capability becomes stale after the microcode
update.
On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2014, H. Peter Anvin wrote:
We should, but this is also part of why we want the early ucode capability.
Well, yes. But that won't help the several stable and LTS distros with
kernels without early ucode update support.
On Sep 18, 2014 5:13 PM, Henrique de Moraes Holschuh h...@hmh.eng.br wrote:
On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2014, H. Peter Anvin wrote:
We should, but this is also part of why we want the early ucode
capability.
Well, yes. But that won't help
The cpuid bit gets twiddled...
On September 18, 2014 5:23:40 PM PDT, Andy Lutomirski l...@amacapital.net
wrote:
On Sep 18, 2014 5:13 PM, Henrique de Moraes Holschuh h...@hmh.eng.br
wrote:
On Thu, 18 Sep 2014, Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2014, H. Peter Anvin wrote:
We
On Sep 18, 2014 5:28 PM, H. Peter Anvin h...@zytor.com wrote:
The cpuid bit gets twiddled...
Yes, but how? I assume that BIOS isn't switching between two
different ucode blobs, and I don't know about any wrcpuid instruction.
So there must be *some* way, at least on new ucode (and maybe on old
The new Haswell microcode update[1] removes the hle (hardware lock
elision) processor capability. And it is not cosmetic, either: Intel TSX
opcodes will cause an illegal opcode trap after the microcode update[2].
This means cpu_info()-x86_capability becomes stale after the microcode
update.
We
On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
The new Haswell microcode update[1] removes the hle (hardware lock
elision) processor capability. And it is not cosmetic, either: Intel TSX
opcodes will cause an illegal opcode trap after the microcode update[2].
This means
We should, but this is also part of why we want the early ucode capability.
On September 18, 2014 12:53:28 PM PDT, Chuck Ebbert cebbert.l...@gmail.com
wrote:
On Thu, 18 Sep 2014 12:14:59 -0700
Andy Lutomirski l...@amacapital.net wrote:
On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
On Thu, 18 Sep 2014 12:14:59 -0700
Andy Lutomirski l...@amacapital.net wrote:
On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
The new Haswell microcode update[1] removes the hle (hardware lock
elision) processor capability. And it is not cosmetic, either: Intel TSX
opcodes will
On Thu, 18 Sep 2014, H. Peter Anvin wrote:
We should, but this is also part of why we want the early ucode capability.
Well, yes. But that won't help the several stable and LTS distros with
kernels without early ucode update support.
--
One disk to rule them all, One disk to find them. One
94 matches
Mail list logo
