qemu-devel
[Top][All Lists]
Advanced

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

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


From: Andrew Baumann
Subject: Re: [Qemu-devel] [PATCH v3 6/7] bcm2836: add bcm2836 soc device
Date: Wed, 13 Jan 2016 00:09:02 +0000

> From: Peter Crosthwaite [mailto:address@hidden
> Sent: Tuesday, 12 January 2016 15:15
> On Tue, Jan 12, 2016 at 2:56 PM, Andrew Baumann
> <address@hidden> wrote:
> >> 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?

Yes, it is a busy-wait in my smpboot blob. (I suppose I could figure out how to 
replace it with an interrupt-driven version, but it seemed like a lot of 
pointless work compared to not starting the CPU.) On a first quick test, that 
property seems to do the trick, thanks.

Andrew

reply via email to

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