qemu-discuss
[Top][All Lists]
Advanced

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

Re: [Qemu-discuss] Running dual-core ARM Cortexa9


From: Peter Maydell
Subject: Re: [Qemu-discuss] Running dual-core ARM Cortexa9
Date: Tue, 22 Dec 2015 21:38:28 +0000

On 22 December 2015 at 20:22, Ilya Katsnelson <address@hidden> wrote:
> Thanks, Peter.
> My final HW platform is an ALTERA's Arria10 FPGA which has 2
> ARM cores. So it would be useful to simulate them correctly.
> But I'll take one core if that's the only thing available.
> However, QEMU has multicore parameters. If the only thing they
> do is just reduce performance, why support them?
> So is there any way to simulate dual ARMs on QEMU?

If you get a working setup that works with one core
(for an ARM CPU which has a multicore variant like the
A9 or A15), then adding '-smp 2' will simulate it with two
cores, and the guest will just work, assuming it's Linux and
built as an SMP aware kernel.

The multicore parameters are useful:
 1) with KVM, when you really do get to use multiple host
CPUs and get a corresponding performance boost
 2) if you're trying to boot a dumb guest OS which insists
on seeing the exact number of cores it expects to see
(there are a few of those out there)
 3) if you wanted to test some bits of the guest kernel
(eg CPU enumeration) which actually behave differently
depending on number of CPUs

But if you just want to run Linux guest code as fast as possible
(and especially if you only care about the userspace code
and not the details of what the kernel is doing) then a single
guest CPU is best.

Note that since we're not a cycle accurate simulator and
we don't emulate caches, being multicore doesn't imply that
we'll necessarily find race conditions, missing memory barriers
and other things that will cause code to fail on real SMP
hardware, even if you use -smp 2.

We're also currently working on making TCG emulation use
multiple host CPUs, at which point you will get a performance
benefit. But right now you just get a bit of extra overhead.

thanks
-- PMM



reply via email to

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