change in 'smp_cpus' at runtime vs vcpu_info?

change in 'smp_cpus' at runtime vs vcpu_info?

[Jes Sorensen]

Hi,

Looking through the KVM qemu code, I see nothing that indicates that
smp_cpus can be increased after qemu is initially launched?

Does anyone see any reason why we couldn't allocate the vcpu_info
array at launch time based on the value of smp_cpus? Right now
vcpu_info is a static array and I would love to get rid of this
limitation if possible.

Cheers,
Jes

Re: change in 'smp_cpus' at runtime vs vcpu_info?

[Glauber Costa]

On Fri, Sep 26, 2008 at 11:17 AM, Jes Sorensen <jes@sgi.com> wrote:
> Hi,
>
> Looking through the KVM qemu code, I see nothing that indicates that
> smp_cpus can be increased after qemu is initially launched?
>
> Does anyone see any reason why we couldn't allocate the vcpu_info
> array at launch time based on the value of smp_cpus? Right now
> vcpu_info is a static array and I would love to get rid of this
> limitation if possible.

it can increase in hw/apic.c. The real limitation is then in the bios.
The APIC tables
used to be populated based on the smp_cpus value, and now are populated based on
MAX_CPUS.



-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: change in 'smp_cpus' at runtime vs vcpu_info?

[Jes Sorensen]

Glauber Costa wrote:
> On Fri, Sep 26, 2008 at 11:17 AM, Jes Sorensen <jes@sgi.com> wrote:
>> Hi,
>>
>> Looking through the KVM qemu code, I see nothing that indicates that
>> smp_cpus can be increased after qemu is initially launched?
>>
>> Does anyone see any reason why we couldn't allocate the vcpu_info
>> array at launch time based on the value of smp_cpus? Right now
>> vcpu_info is a static array and I would love to get rid of this
>> limitation if possible.
> 
> it can increase in hw/apic.c. The real limitation is then in the bios.
> The APIC tables
> used to be populated based on the smp_cpus value, and now are populated based on
> MAX_CPUS.

Hmmm. I don't see any reference to MAX_CPUS in hw/apic.c, any chance you
can give me a pointer?

Thanks,
Jes

Re: change in 'smp_cpus' at runtime vs vcpu_info?

[Glauber Costa]

On Fri, Sep 26, 2008 at 11:31 AM, Jes Sorensen <jes@sgi.com> wrote:
> Glauber Costa wrote:
>>
>> On Fri, Sep 26, 2008 at 11:17 AM, Jes Sorensen <jes@sgi.com> wrote:
>>>
>>> Hi,
>>>
>>> Looking through the KVM qemu code, I see nothing that indicates that
>>> smp_cpus can be increased after qemu is initially launched?
>>>
>>> Does anyone see any reason why we couldn't allocate the vcpu_info
>>> array at launch time based on the value of smp_cpus? Right now
>>> vcpu_info is a static array and I would love to get rid of this
>>> limitation if possible.
>>
>> it can increase in hw/apic.c. The real limitation is then in the bios.
>> The APIC tables
>> used to be populated based on the smp_cpus value, and now are populated
>> based on
>> MAX_CPUS.
>
> Hmmm. I don't see any reference to MAX_CPUS in hw/apic.c, any chance you
> can give me a pointer?

sorry. That's not apic (damn acronyms), It's acpi.
But the reference to MAX_CPUS is at bios/rombios32.c when building the tables.
the acpi code just fire them out.

>
> Thanks,
> Jes
>



-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: change in 'smp_cpus' at runtime vs vcpu_info?

[Jes Sorensen]

Glauber Costa wrote:
> On Fri, Sep 26, 2008 at 11:31 AM, Jes Sorensen <jes@sgi.com> wrote:
>> Hmmm. I don't see any reference to MAX_CPUS in hw/apic.c, any chance you
>> can give me a pointer?
> 
> sorry. That's not apic (damn acronyms), It's acpi.
> But the reference to MAX_CPUS is at bios/rombios32.c when building the tables.
> the acpi code just fire them out.

Oh, that seems to be x86 gibberish though :-)

Well the point is that qemu-kvm.c seems to loop over the vcpu_info array
based on smp_cpus, so if we hotplug a CPU and smp_cpus isn't updated,
which I cannot find any place that does, then we'll end up looping over
only a subset of cpus?

or am I missing something here?

Cheers,
Jes