qemu-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]