RE: [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

["Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>]

> -----Original Message-----
> From: Ashok Raj [mailto:ashok.raj@intel.com] 
> Sent: Thursday, September 01, 2005 3:27 PM
> To: Protasevich, Natalie
> Cc: Ashok Raj; shaohua.li@intel.com; zwane@arm.linux.org.uk; 
> akpm@osdl.org; ak@suse.de; lhcs-devel@lists.sourceforge.net; 
> linux-kernel@vger.kernel.org; hotplug_sig@lists.osdl.org
> Subject: Re: [patch 1/1] Hot plug CPU to support physical add 
> of new processors (i386)
> 
> On Thu, Sep 01, 2005 at 04:09:09PM -0500, Protasevich, Natalie wrote:
> > > 
> > > > Current IA32 CPU hotplug code doesn't allow bringing up
> > > processors that were not present in the boot configuration. 
> > > > To make existing hot plug facility more practical for 
> physical hot 
> > > > plug, possible processors should be encountered during boot for 
> > > > potentual hot add/replace/remove. On ES7000, ACPI marks all the 
> > > > sockets that are empty or not assigned to the partitionas as 
> > > > "disabled". The patch allows arrays/masks with APIC info
> > > for disabled
> > > > processors to be
> > > 
> > > This sounds like a cluge to me. The correct 
> implementation would be 
> > > you would need some sysmgmt deamon or something that 
> works with the 
> > > kernel to notify of new cpus and populate apicid and grow 
> > > cpu_present_map. Making an assumption that disabled 
> APICID are valid 
> > > for ES7000 sake is not a safe assumption.
> > 
> > Yes, this is a kludge, I realize that. The AML code was not 
> there so 
> > far (it will be in the next one). I have a point here 
> though that if 
> > the processor is there, but is unusable (what "disabled" 
> means as the 
> > ACPI spec says), meaning bad maybe, then with physical hot 
> plug it can 
> > certainly be made usable and I think it should be taken into 
> > consideration (and into configuration). It should be counted as 
> > possible at least, with hot plug, because it represent 
> existing socket.
> 
> 
> I think marking it as present, and considering in 
> cpu_possible_map is perfectly ok. But we would need more glue 
> logic, that is if firmware marked it as disabled, then one 
> would expect you then run _STA and find that the CPU is now 
> present and functional as reported by _STA, then the CPU is onlinable.
> 
> So if _STA can work favorably in your case you can use it to 
> override the disabled setting at boot time which would be 
> prefectly fine.
> > 

We have a server control mechanism that sends appropriate messages and
notifications to the OS. The BIOS handles all the hardware level stuff,
including bringing the processor into appropriate state. The user level
driver handles those messages and uses OS facilities to bring up
processors and make them operational.

--Natalie 
> -- 
> Cheers,
> Ashok Raj
> - Open Source Technology Center
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/