Gleb Natapov wrote:
> On Thu, Mar 04, 2010 at 12:34:22AM +0100, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Mon, Mar 01, 2010 at 06:17:22PM +0100, Jan Kiszka wrote:
>>>> As we hard-wire the BSP to CPU 0 anyway and cpuid_apic_id equals
>>>> cpu_index, cpu_is_bsp can also be based on the latter directly. This
>>>> will help an early user of it: KVM while initializing mp_state.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
>>>> ---
>>>> hw/pc.c | 3 ++-
>>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/hw/pc.c b/hw/pc.c
>>>> index b90a79e..58c32ea 100644
>>>> --- a/hw/pc.c
>>>> +++ b/hw/pc.c
>>>> @@ -767,7 +767,8 @@ static void pc_init_ne2k_isa(NICInfo *nd)
>>>>
>>>> int cpu_is_bsp(CPUState *env)
>>>> {
>>>> - return env->cpuid_apic_id == 0;
>>>> + /* We hard-wire the BSP to the first CPU. */
>>>> + return env->cpu_index == 0;
>>>> }
>>> We should not assume that. The function was written like that
>>> specifically so the code around it will not rely on this assumption.
>>> Now you change that specifically to write code that will do incorrect
>>> assumptions. I don't see the logic here.
>> The logic is that we do not support any other mapping yet - with or
>> without this change. Without it, we complicate the APIC initialization
>> for (so far) no good reason. Once we want to support different BSP
>> assignments, we need to go through the code and rework some parts anyway.
>>
> As far as I remember the only part that was missing was a command line to
> specify apic IDs for each CPU and what CPU is BSP. The code was ready
> otherwise. I's very sad if this was broken by other modifications. But
> changes like that actually pushes us back from our goal. Why not rework
> code so it will work with correct cpu_is_bsp() function instead of
> introducing this hack?
If you can confirm that there is a serious use case behind it, I will
look into this again. But so far, I did not find it.
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
