[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 revision). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |