On 06/08/10 03:56, Anthony Liguori wrote:
> On 06/07/2010 08:01 PM, Paul Brook wrote:
>>> diff --git a/hw/realview.c b/hw/realview.c
>>> index a36bdbe..8dcef80 100644
>>> --- a/hw/realview.c
>>> +++ b/hw/realview.c
>>> @@ -444,9 +444,9 @@ static QEMUMachine realview_eb_mpcore_machine = {
>>> .init = realview_eb_mpcore_init,
>>> .opts_default = (QemuOptValue[]) {
>>> QOPT_VALUE("default_drive", "scsi"),
>>> + QOPT_VALUE("max_cpus", "4"),
>>> { /* end of list */ }
>>> },
>>> - .max_cpus = 4,
>>> };
>>>
>> By my reading this allows the user to modify this value. If so it is
>> wrong.
>
> max_cpus is complicated because it was used for multiple purposes.
>
> I think max_cpus ought to be configurable. The reason it's useful to
> configure it that it lets a downstream specify a recommended max cpu
> that's mostly relevant from a scalability perspective. For instance,
> you may want to set the pc max_cpus to 64 since this is the highest that
> KVM supports today.
max_cpus was designed to set the upper limit of allowable cpus on a
system. The main intention for it was to offer limits to things like
SeaBIOS to tell it how many entries to put into the BIOS tables for
systems where we allow hotplug etc. It was not meant to be used to set
limits higher than what the system is able to support, like on with the
current ACPI implementation in SeaBIOS we cannot go above 255 on PC
hardware.
However I don't really see the point in allowing max_cpus to be
configurable on a system like this where 4 is the possible max, per what
Paul is saying. If the user wants to run < 4 cpus, he/she should specify
-smp X with 1 <= X <= 4.
Cheers,
Jes
