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

[Borislav Petkov <bp@suse.de>]

On Wed, Jan 28, 2015 at 12:10:43AM +0000, Andrew Cooper wrote:
> There was a thread on xen-devel but I cant currently find it in the
> archives.
> 
> To the best of my memory,  it was a 4 core APU system where the BIOS had
> updated the microcode on cpu 0 but left 1-3 at a lower patch level. 
> Every time the reporter tried creating an HVM guest (i.e. entering SVM
> non-root mode), the system reset.
> 
> The instability was sorted by ensuring each core was at the same
> microcode level.

That sounds like a BIOS bug to me, frankly.

> As Xen updates microcode one cpu at a time from 0, it could easily
> create a similar situation if microcode is updated after VMs have been
> started.  Come to think of it, this is also an impending problem for PVH
> dom0 systems.

The common way for doing microcode updates is to update all cores at
the same time, possibly. Or at least as close to one another in time as
possible.

Now, we do two methods:

* the early update which should be done as early as possible during
boot. I don't think that should be a problem wrt to guests if you do it
early enough.

* the late update is an addition to the early one to cover the cases of
long running systems where a reboot is prohibitively painful. With that,
as with the early method, you would want to update all hardware cores in
one go.

Now, this is where it becomes tricky for virt: you need to stop guests,
do the update and then resume them. Even worse, if all of a sudden you
want to hide hardware features and/or instructions like HSW TSX for
example, you most likely want to even avoid the late update and warn the
admin that she has to reboot that machine and apply microcode with the
early method.

So this should be the gist of it...

-- 
Regards/Gruss,
    Boris.

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