Re: [Xen-devel] [PATCH] misc/xenmicrocode: Upload /lib/firmware/<some blob> to the hypervisor

[Borislav Petkov <bp@xxxxxxx>]

On Thu, Jan 29, 2015 at 03:01:22PM -0200, Henrique de Moraes Holschuh wrote:
> No, I have not.  It was a direct observation based on the fact that
> there is a report of a system misbehaving because of mismatched AMD
> microcode in this very thread.  Now, if someone from AMD did state that
> they are enforcing that the processor should work with mismatched
> microcode at all times,

It was a dumb BIOS bug, if at all. Drop it already.

<snip drivel about mismatched ucode which is completely beside the point
  here>

<snip more hypothetical drivel which I don't even know what's supposed
 to mean>

> The restriction is in the Intel SDM, section 9.11.6.2, (vol. 3A, page
> 9-35):
> 
> "9.11.6.3   Update in a System Supporting Intel Hyper-Threading
> Technology:

Ah that.

We have that serialization from the design of the late reloading by
iterating over all cores in succession. After we update the first
logical core of two-threads core which share the microcode engine, the
updated version is visible on the second hyperthread and we don't do the
update there.

If you're seeing actual bug reports about that, feel free to CC me.

> You know my position on this: I consider it a valid advanced use-case,
> for those who really know what they're doing. But it shouldn't be the
> default mode of operation for Linux distros, and one shouldn't assume
> it is going to be safe without extra data (thus the "for those who
> really know what they're doing").

I don't see the reason to force people who update the software on their
machines to reboot them just because a new microcode patch was released
for their hw.

So, for those cases, we can simply use the late method. During the
update, the initrd gets regenerated with the new patch anyway so when
they reboot next time, they get the update.

But forcing them to reboot specifically just because they updated their
microcode patch and that microcode patch is self-contained is completely
unnecessary.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel