On Fri, Nov 22, 2013 at 09:42:28AM +0900, HATAYAMA Daisuke wrote:
> (2013/11/22 6:33), Vivek Goyal wrote:
> >On Thu, Nov 21, 2013 at 11:00:44AM +0900, HATAYAMA Daisuke wrote:
> >
> >[..]
> >>@@ -2122,6 +2129,19 @@ void generic_processor_info(int apicid, int version)
> >> bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> >> phys_cpu_present_map);
> >>
> >>+ if (disabled_cpu_apicid != BAD_APICID &&
> >>+ disabled_cpu_apicid != boot_cpu_physical_apicid &&
> >
> >Hi Hatayama,
> >
> >So we are comparing disabled_cpu_apicid with boot_cpu_physical_apicid
> >to make sure that one can not disable the cpu we are booting on. Can
> >we just read the apic id of booting cpu in local variable and compare
> >against that?
> >
> >Something like as follows.
> >
> > if (disabled_cpu_apicid != BAD_APICID &&
> > disabled_cpu_apicid == apicid &&
> > disabled_cpu_apicid != read_apic_id()) {
> > /* Disable cpu */
> > }
> >
> >If above works, you will not need first patch in the series?
> >
>
> Yes, I came up with the idea, too. But doing this means we leave two different
> ways boot_cpu_physical_apicid is used at boot, which seemed incomplete as a
> patch. Also, then we could even lost the reason why boot_cpu_physical_apicid
> exists.
>
> But, it's true that the 1st patch causes one more reviewing point. I'll
> remove it and fix the 2nd patch just as you suggested here.
I would say that do the boot_cpu_physical_id related cleanup in a separate
series. If we keep this patch really simple without fear of breaking
anything else, acking and committing the patch becomes easier.
Feel free to post boot cpu related cleanup in a separate series.
Thanks
Vivek
