[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 2/2] microcode: reject late ucode loading if any core is parked
On 21.11.2019 12:51, Chao Gao wrote: > On Thu, Nov 21, 2019 at 11:21:13AM +0100, Jan Beulich wrote: >> On 21.11.2019 00:05, Chao Gao wrote: >>> If a core with all of its thread being parked, late ucode loading >>> which currently only loads ucode on online threads would lead to >>> differing ucode revisions in the system. In general, keeping ucode >>> revision consistent would be less error-prone. To this end, if there >>> is a parked thread doesn't have an online sibling thread, late ucode >>> loading is rejected. >> >> I'm confused. I thought we had agreed that the long term solution >> would be to briefly bring online a thread of cores with all their >> threads parked. > > I don't remeber that we reached such an aggrement. But if it happened, > I am really sorry for forgeting it. > > Actually, I think Dom0 has the information (cpu topology and each cpu's > offline/online status) to decide if there is a parked core or not. > IMO, rejecting late loading in this case is just a defense check. Dom0 > is able to correct the situation by bringing up some cpus. Dom0 can _fully_ bring up CPUs, but not with the intent of _just_ getting their ucode updated. >> What you do here was meant to be a temporary step >> only for 4.13, for which it is too late now (unless Jürgen >> indicates otherwise). >> >>> --- a/xen/arch/x86/microcode.c >>> +++ b/xen/arch/x86/microcode.c >>> @@ -584,6 +584,51 @@ static int do_microcode_update(void *patch) >>> return ret; >>> } >>> >>> +static unsigned int unique_core_id(unsigned int cpu, unsigned int >>> socket_shift) >>> +{ >>> + unsigned int core_id = cpu_to_cu(cpu); >>> + >>> + if ( core_id == INVALID_CUID ) >>> + core_id = cpu_to_core(cpu); >>> + >>> + return (cpu_to_socket(cpu) << socket_shift) + core_id; >>> +} >>> + >>> +static int has_parked_core(void) >>> +{ >>> + int ret; >>> + unsigned int cpu, max_bits, core_width; >>> + unsigned int max_sockets = 1, max_cores = 1; >>> + unsigned long *bitmap; >>> + >>> + if ( !park_offline_cpus ) >>> + return 0; >>> + >>> + for_each_parked_cpu(cpu) >>> + { >>> + /* Note that cpu_to_socket() get an ID starting from 0. */ >>> + max_sockets = max(max_sockets, cpu_to_socket(cpu) + 1); >>> + max_cores = max(max_cores, cpu_data[cpu].x86_max_cores); >>> + } >>> + >>> + core_width = fls(max_cores); >>> + max_bits = max_sockets << core_width; >> >> Isn't this off by one? If max_cores is 1, you don't need to shift >> max_sockets (or the cpu_to_socket() value in unique_core_id()) at >> all, for example. >> >> With this in mind, instead of the park_offline_cpus check at the >> top of the function, wouldn't it make sense to check here whether >> max_sockets and max_cores are both still 1, in which case at >> least one thread of the only core of the only socket in the system >> is obviously still online (the one we're running on)? > > Agree. Will follow your suggestion. Aiui it'll be correct again only if the parked map gets allocated unconditionally. 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 |