[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v3 6/7] bcm2836: add bcm2836 soc device

From: Peter Crosthwaite
Subject: Re: [Qemu-arm] [PATCH v3 6/7] bcm2836: add bcm2836 soc device
Date: Tue, 12 Jan 2016 15:14:36 -0800

On Tue, Jan 12, 2016 at 2:56 PM, Andrew Baumann
<address@hidden> wrote:
> Hi Peter,
> Thanks again for the reviews.
>> From: Peter Crosthwaite [mailto:address@hidden
>> Sent: Monday, 11 January 2016 19:57
>> On Thu, Dec 31, 2015 at 04:31:33PM -0800, Andrew Baumann wrote:
>> > +    /* TODO: probably shouldn't be using smp_cpus here */
>> I agree. I have started ignoring smp_cpus completely for new ARM SoCs,
>> as if you change the number of CPUs for a SoC, it is not that SoC
>> anymore. The virt platform is suitable for CPU scalability, whereas
>> with ARM SoCs, cpu # variation is invalid.
>> > +    assert(smp_cpus <= BCM2836_NCPUS);
>> > +    for (n = 0; n < smp_cpus; n++) {
>> So can we just use BCM2836_NCPUS here as the loop bound? Any
>> conditionals out there check the existance of CPUs can be removed or
>> promoted to assert() as a BCM2836 must always have 4 CPUs.
> I'd love to do that, but there's at least one good reason to respect the -smp 
> parameter and not start all the CPUs: with full-system emulation, qemu is 
> noticeably faster emulating a single-core target than multi-core. E.g., Linux 
> boots fine with -smp 1 (it fails to start the other CPUs but proceeds with 
> just one), and many users will be better off running it this way, so I 
> definitely don't want to break that.

What are the secondary CPUs doing in this case? In most systems they
end up penning on a WFI/WFE. Is Linux actually trying to do the SMP
bringup - are you are getting a secondary entry point?

If not and it is just a busy wait killing perf, start-powered-off
property might help. Is the firmware responsible for secondary-penning
an actual busy-wait or does it involve power-control periphs etc?


> I tried always initing all 4 CPUs in bcm2836_init, and only starting a 
> configurable number (based on a property) in realize. However, arm 
> cpu_exec_init already adds the cpu to the global list of all CPUs, and if you 
> try to start the system in this state it quickly segfaults on uninitialized 
> state in the CPU, so it seems we shouldn't even init CPUs that won't later be 
> started. However, I can't refer to properties in the _init method, which is 
> why I'm stuck using the smp_cpus global.
> If you have a better suggestion, I'm all ears :) Would it make sense to defer 
> calling init() until the realize method, when we can access a property?
> Cheers,
> Andrew

reply via email to

[Prev in Thread] Current Thread [Next in Thread]