On Mon, Oct 12, 2015 at 10:00:19AM +0300, Pavel Fedin wrote:
> Hello!
>
> > Before this patch it would complain that the requested
> > number of cpus was greater than 123, but for gicv2 configs, it
> > should complain that the number is greater than 8.
>
> Actually, gicv2 code has own check, an
Hello!
> Before this patch it would complain that the requested
> number of cpus was greater than 123, but for gicv2 configs, it
> should complain that the number is greater than 8.
Actually, gicv2 code has own check, and it would complain about >8 CPU (see
arm_gic_common_realize()).
Kind rega
On Fri, Oct 09, 2015 at 05:45:24PM +0100, Peter Maydell wrote:
> On 6 October 2015 at 15:37, Andrew Jones wrote:
> > We should always go through VirtBoardInfo when we need the memmap.
> > To avoid using a15memmap directly, in this case, we need to defer
> > the max-cpus check from class init time
On 6 October 2015 at 15:37, Andrew Jones wrote:
> We should always go through VirtBoardInfo when we need the memmap.
> To avoid using a15memmap directly, in this case, we need to defer
> the max-cpus check from class init time to instance init time. In
> class init we now use MAX_CPUMASK_BITS for
We should always go through VirtBoardInfo when we need the memmap.
To avoid using a15memmap directly, in this case, we need to defer
the max-cpus check from class init time to instance init time. In
class init we now use MAX_CPUMASK_BITS for max_cpus initialization,
which is the maximum QEMU suppor
