[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [patch 2/2] QEMU BOCHS bios patches to use maxcpus valu
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [patch 2/2] QEMU BOCHS bios patches to use maxcpus value. |
Date: |
Sun, 12 Jul 2009 16:36:57 +0300 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2 |
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