[SMP BUG?] the return value of is_smp() is bug?

[long.wanglong]

On 2014/9/1 18:19, Russell King - ARM Linux wrote:
> Firstly, do not send multiple copies of your message to mailing lists,
> certainly not within the three hours that you sent your three copies.
> If one of the addresses you sent the message to bounces, then it is
> *only* that one recipient who doesn't get your message, everyone else
> receives a copy.  So, there's now three copies of your message in the
> list archives, and people could end up replying to different messages.
> 
> On Mon, Sep 01, 2014 at 07:35:34PM +0800, Wang Long wrote:
>> Hi,all
>>
>> In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y 
>> in .config file. the secondary core can not boot.
>>
>> when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file,
>> the secondary core can boot.
>>
>> But this does not happen in kernel 3.10 lts kernel, Whether the 
>> CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot.
>>
>> Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel 3.17-rc2 ? 
> 
> I think the answer is neither, because when the kernel is run on /real/
> hardware:
> 
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=2514
> 
> it boots fine, bringing up all four CPUs.
> 
>> config:     set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
>> command:    # qemu-system-arm -M vexpress-a9 -smp 2  -m 128M -kernel arch/arm/boot/zImage -nographic
> 
> I've no idea how qemu works here, but if the CPU doesn't indicate that
> it's a SMP capable CPU, we will disable SMP extensions.
> 
>> The output:
>>
>> ..........
>> is_smp() return false;
>> CPU: Testing write buffer coherency: ok
>> missing device node for CPU 0
>> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> Setting up static identity map for 0x604643d8 - 0x60464430
>> Brought up 1 CPUs
>> SMP: Total of 1 processors activated.
>> CPU: All CPU(s) started in SVC mode.
>> ...........
> 
> You have decided that you'll edit the kernel messages, removing at least
> some of the information that could be relevant to the issue.  Please,
> only cut kernel messages when you are absolutely certain that they are
> not relevant to the problem you're reporting.
> 
> However, I don't think it would help much - I suspect that qemu doesn't
> provide emulation of the SCU base address register, and that's what your
> problem is.  qemu needs to be fixed in that regard.
> 

Hi,Russell King

Thank you for your reply. I will not send multiple copies of message to mailing lists.
The problem is that qemu doesn't provide emulation of the SCU base address register.