[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v1 2/2] common/page_alloc: don't idle-scrub before microcode update

>>> On 27.11.18 at 11:10, <julien.grall@xxxxxxx> wrote:
> Hi,
> On 11/27/18 10:00 AM, Sergey Dyasli wrote:
>> Some x86 CPUs has errata regarding microcode updates. The most notorious
>> is Broadwell's BDX90: "Loading Microcode ... May Result in a System Hang".
>> (URL: 
> https://www.intel.com/content/dam/www/public/us/en/documents/specification-up 
> dates/xeon-e7-v4-spec-update.pdf)
>> CPUs are supposed to be idle during initial microcode update. Idle-scrub
>> changes this, making a CPU to go scrubbing (memset) right after it was
>> brought up. This can get in a way of microcode update for other CPUs,
>> which results in a system hang:
>>      [    0.000000] CPU Vendor: Intel, Family 6 (0x6), Model 71 (0x47), 
> Stepping 1 (raw 00040671)
>>      ...
>>      [    2.598813] HVM: Hardware Assisted Paging (HAP) detected
>>      [    2.600211] HVM: HAP page sizes: 4kB, 2MB, 1GB
>>      [    0.000000] microcode: CPU2 updated from revision 0x11 to 0x1e, date 
> = 2018-04-03
>>      [    0.000000] microcode: CPU4 updated from revision 0x11 to 0x1e, d€ 
> [2J[1;1H[2J
>> Prevent this situation by disabling idle scrubbing until
>> SYS_STATE_smp_booted is reached.
> I am not aware of any issue on Arm that requires delaying the idle 
> scrubbing. It is actually probably better to avoid delaying it as it may 
> take a long time to boot all CPUs on platform with a high number of 
> cores (48 cores or upper).

And even on x86 it would perhaps be better to delay things only
if there really is a problem (i.e. Broadwell with too low a ucode


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.