Re: [SeaBIOS] [PATCH 3/3] Take in account hot(un)plugged cpus on reboot

[Igor Mammedov]

----- Original Message -----
> From: "Gleb Natapov" 
> To: "Igor Mammedov" 
> Cc: "Kevin O'Connor" , "jan kiszka" , [e-mail]
> Sent: Thursday, March 15, 2012 3:13:58 PM
> Subject: Re: [SeaBIOS] [PATCH 3/3] Take in account hot(un)plugged cpus on reboot
>
> On Thu, Mar 15, 2012 at 10:08:17AM -0400, Igor Mammedov wrote:
> > > Good point. You mean we need a list of apic ids of available cpus
> > > right?
> > > Can SeaBIOS build this list by reading apic id in
> > > smp_ap_boot_code?
> >
> > I've looked at how tables are build. It seems that it's not hard
> > and sufficient
> > to build an equivalent temporary byte array of (un)available apic
> > ids that
> > corresponds to 0xaf00 bitmap at boot time, under following
> > restriction:
> > apic id shall be in range [0..max_cpus)
>
> Why this restriction? ap bootstrap code can grab array entry with
> atomic
> operation and store its apic id there.

we need to know in advance how large array to allocate.
and if apic id is to serve as index in this array and to correspond to
appropriate bit in 0xaf00 bitmap.

Why limiting apic id range to [0..max_cpus) is bad thing?
> >  * this will allow to allocate array where apic id will serve
> >  as index,
> >  thus making it equvivalent to 0xaf00 bitmap.
> >  * and easily fill this array in smp_ap_boot_code without
> >  inventing
> >  and using mutexes/spinlocks in smp_ap_boot_code.
> >
> >
> > This will require cooperation from qemu side. apic id could be
> > checked
> > somewhere in device_add command handler call chain or at cpu object
> > creation
> > time.
> >
> > Jan,
> >   What do you think about setting such restriction on apic id of
> >   cpus in
> >   qemu?
>
> We do have such restriction currently. A couple of years ago I
> removed
> it from the kernel, but qemu and current bios code still has it.