lkml.org 
[lkml]   [2013]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:x86/bsp-hotplug] x86, apic: Disable BSP if boot cpu is AP
On 11/12/2013 02:20 AM, HATAYAMA Daisuke wrote:
>
> Thanks for pointing out that. I think the first two issues has already been
> fixed in v3 version. I've just posted v5 version a little time ago.

OK, I see now. It looks like it was radically changed, so the branch in
the -tip tree is completely stale.

> BTW,
> I changed the basic design at v4 where we specify the initial APIC ID of
> the
> processor we want to disable in the kdump 2nd kernel from the the 1st
> kernel
> through newly introduced disable_cpu_apicid kernel parameter; it might be
> similar to the idea you described in the patch description of tip tree.

> I don't know the third issue. Could you explain what kind of things can
> happen on clustered system? Only IA32_APIC_BASE MSR is no longer trusted? Or are
> there other things we can possibly no longer trust?

On a clustered system, the CPU APICIDs will duplicate, as only a
hardware-specific method can obtain the cluster-wide ID. That is why we
have struct apic.get_apic_id().

IA32_APIC_BASE_MSR is another matter... it doesn't even exist on older
hardware. It might be as simple as if IA32_APIC_BASE_MSR doesn't exist
we ignore this whole mechanism (this applies to P5 and earlier, but also
modern derivatives like Quark) but we can't blindly touch this register
as it might trap. At the very least it needs to be rdmsr_safe().

> Also, could you explain what you suggest to deal with the issue in more
> detail?

I think the only thing we can do is to record in the first kernel on
which CPU we were booted on. Then there is no need to look at the BSP
flag in APIC_BASE_MSR at all or anything similar.

-hpa



\
 
 \ /
  Last update: 2013-11-12 17:21    [W:0.064 / U:1.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site