Re: [Qemu-devel] [patch 2/2] QEMU BOCHS bios patches to use maxcpus value.

[Avi Kivity <avi@redhat.com>]

On 07/12/2009 04:23 PM, Anthony Liguori wrote:
>>> If nothing else, maxcpus ==smp_cpus under QEMU because we don't do 
>>> CPU hotplug (and I don't think we should).
>>>
>>
>> Why shouldn't we do cpu hotplug?
>
>
> I don't think we should do cpu hotplug via ACPI. 

Well, that's a different story from "we shouldn't do cou hotplug".

> I don't think ACPI actually models CPU hotplug and the fact that this 
> works with Linux in KVM is a happy accident. 

I think it's based on the Unisys machines and thus no accident.

> VMware only supports CPU hotplug for Windows 7/2k8 guests so I'm 
> assuming their using Viridian PV extensions to do it.

I don't recall seeing hotplug support in Viridian.  Further, Windows 
2008 appears to support cpu hotplug on bare metal.  My guess is that it 
uses ACPI, perhaps with an additional vendor driver.

> I think we should go the PV route for Linux too. 

Seems like needless churn, plus disabling that functionality for older 
kernels.

> I'd rather see us create all vcpu threads at once and then let the 
> guest offline each vcpu via a PV notification. 

That doesn't work, for example, when the guest reboots into an older 
version of itself.  It also gives control of resource usage to the guest 
instead of the host.  The latter issue can be fixed using control 
groups, but I'd rather not break it in the first place.

> I don't see a lot of value in spawning/terminating vcpu threads 
> dynamically and it adds an awful lot of complexity.  There's very 
> little overhead to an idle thread.

Can you elaborate on the complexity you think dynamic vcpu threads add?  
IIRC there's some synchronization to be done at startup, but nothing 
that merits the label "awful".

-- 
error compiling committee.c: too many arguments to function