[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v10 00/16] improve late microcode loading
On 17.09.2019 09:09, Chao Gao wrote: > On Fri, Sep 13, 2019 at 10:47:36AM +0200, Jan Beulich wrote: >> On 12.09.2019 09:22, Chao Gao wrote: >>> This series includes below changes: >>> 1. Patch 1-11: introduce a global microcode cache and some cleanup >>> 2. Patch 12: synchronize late microcode loading >>> 3. Patch 13: support parallel microcodes update on different cores >>> 4. Patch 14: block #NMI handling during microcode loading >>> 5. Patch 15: disable late ucode loading due to BDF90 >>> 6. Patch 16: call wbinvd() conditionally >> >> I don't know why it didn't occur to me earlier, but what about >> parked / offlined CPUs? They'll have their ucode updated when they >> get brought back online, but until then their ucode will disagree >> with that of the online CPUs. For truly offline CPUs this may be >> fine, but parked ones should probably be updated, perhaps via the >> same approach as used when C-state data becomes available (see >> set_cx_pminfo())? > > Yes. It provides a means to wake up the parked CPU and a chance to run > some code (like loading ucode). But parked CPUs are cleared from > sibling info and cpu_online_map (see __cpu_disable()). If parallel > ucode loading is expected on parked CPUs, we should be able to > determine the primary threads and the number of cores no matter it is > online or parked. To this end, a new sibling map should be maintained > for each CPU and this map isn't changed when a CPU gets parked. Would this really be necessary? If any thread in a core is not parked, bringing up the parked threads is unnecessary. If all threads of a core are parked, simply nudge the thread with ID zero? > In Linux kernel, the approach is quite simple: late loading is > prohibited if any CPU is parked; admin should online all parked CPU > before loading ucode. Well, this is certainly an option, but (as per above) I think this is too rigid: Refusing the operation would be necessary only if there's a core with all of its threads parked. (I'd in particular like late loading to work in SMT-disabled mode.) 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 |