Re: [Qemu-arm] [Qemu-devel] [PATCH] hw: add .min_cpus and .default_cpus fields to machine_class

[Philippe Mathieu-Daudé]

On 11/06/2017 08:33 PM, Alistair Francis wrote:
> On Mon, Nov 6, 2017 at 3:21 PM, Emilio G. Cota <address@hidden> wrote:
>> On Mon, Nov 06, 2017 at 14:32:35 -0800, Alistair Francis wrote:
>>> Sorry for the silence here, I noticed these were broken just before I
>>> went on holidays but didn't get a chance to fix anything.
>>>
>>> For the Xilinx case I was thinking of patching the machine code to
>>> sanely follow the -smp option.
>>>
>>> -smp 1 -> Only create 1 A53
>>> -smp 4 -> Create 4 A53s
>>> -smp 6 -> Create all the CPUs
>>>
>>> I see a lot of advantages in not forcing the smallest number of CPUs
>>> to be 4 unless we really have to.
>>>
>>> I do see a nice advantage in being able to set the default smp option
>>> to something not 1 so the default closely matches hardware, but users
>>> can override that if they want to.
>>>
>>> So for the patch below I like the default_cpus option, but for Xilinx
>>> at least I would like to patch the logic to follow the -smp option
>>> instead of force a minimum.
>>
>> Agreed, honouring -smp would be the right fix.
>> Just note that since this is a regression we need the fix to
>> be in for 2.11.

Can we revert some patches to avoid the 2.11 regression and take time to
see how to fix this correctly instead?

The -smp help is:

-smp
[cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads][,sockets=sockets]

How would we start a Cortex-R52?

default would be: -smp cores=4,lockstep
so we can disable DCLS with: -smp cores=8

having Lockstep not being 2N cores but aliased as N, the only interest
being injecting fault (or actually 2 cores, but 1 stopped, the guest not
aware of that).

The ZynqMP indeed has 6 CPUs, why not add apu/rpu options for ARM?

4+2=6 cores:
-smp apus=4,rpus=2

4+1=5 cores
-smp apus=4,rpus=2:lockstep

There will always be 6 cores to this ZynqMP, why want to have less than
4 APUs? I'd rather have 4 APUs, all of them can be offlined /
hotplugged, but they need to be instantiated and machine-initialized.

> Ok, I can spin up a patch for the Xilinx boards in the next day (maybe 2)
> 
>>
>> I just took a look at the non-Xilinx boards. It seems simple enough to
>> substitute the hard-coded value for smp_cpus, but yet again
>> I see "Property" structs that I'm not sure what to do with.
>> For instance, bcm2836.c:152:
>>
>> static Property bcm2836_props[] = {
>>     DEFINE_PROP_UINT32("enabled-cpus", BCM2836State, enabled_cpus, 
>> BCM2836_NCPUS),
>>     DEFINE_PROP_END_OF_LIST()
>> };
>>
>> What is the purpose here? To enable/disable CPUs with -global args,
>> just like it's done for the Xilinx boards? Shouldn't we just use
>> -smp for that?
> 
> Hmm...
> 
>>
>> Also, note that I don't have a way to test these boards, which
>> explains why I'm reluctant to change board code. But of
>> course if board maintainers step in, I'm all for it :-)
> 
> Yeah, I see.
> 
> What about if we set default_cpus to the -smp option that is expected.
> Then on some of the older boards (like the bcm2836) we print a warning
> in the machine init() if the -smp option doesn't match that?
> 
> That way the default args work, we allow users to specify a overwrite
> but we warn them that it might not work and it ensures all boards
> follow a similar flow.
> 
> Then if we can test the boards and know that -smp 1 works we can
> remove the warning.
> 
> Thanks,
> Alistair
> 
>>
>> Thanks,
>>
>>                 Emilio
>>
>