Messages in this thread | | | Date | Fri, 7 Nov 2014 16:40:00 -0200 | From | Henrique de Moraes Holschuh <> | Subject | Re: [PATCH 6/8] x86, microcode, intel: use cpuid explicitly instead of sync_core |
| |
On Fri, 07 Nov 2014, Borislav Petkov wrote: > On Mon, Sep 08, 2014 at 02:37:52PM -0300, Henrique de Moraes Holschuh wrote: > > The protocol to safely read MSR 8BH, described in the Intel SDM vol 3A, > > section 9.11.7.1, explicitly determines that cpuid with EAX=1 must be > > used between the wrmsr(0x8B, 0); and the rdmsr(0x8B). > > > > The microcode driver was abusing sync_core() to do this, probably > > because it predates by nearly a decade the current "asm volatile > > (:::"memory")" implementation of native_cpuid(), which is required for > > the Intel MSR 8BH access protocol. > > Huh, what? Have you taken a look at sync_core() first?
Yes, I did.
> > sync_core() semanthics are that of being a speculative execution > > barrier, and not "run cpuid with EAX=1". > > Again, what?
sync_core() is a speculative execution barrier. That's what it is documented to do. That's the reason _every_ caller other than the microcode drivers call it.
In i486, sync_core() does a jmp.
In i586 and above, and x86-64, sync_core() does a cpuid(1).
sync_core() doesn't expect that its callers really want a cpuid(1). If we ever get a reason to use some other way to insert a speculative execution barrier, sync_core() is likely to switch to it.
> What is the problem again?
No real problem, other than the fact that the microcode drivers call sync_core() for what might as well be considered an internal implementation detail of sync_core().
-- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
| |