Re: [libvirt] [RFC 12/42] pc: initialize legacy hotplug only for 2.6 and older machine types
On Wed, May 11, 2016 at 03:50:39PM +0200, Igor Mammedov wrote:
On Tue, 10 May 2016 17:24:14 -0300 Eduardo Habkost <ehabkost@redhat.com> wrote:
On Mon, May 02, 2016 at 02:33:21PM +0200, Igor Mammedov wrote:
on old machine types CPU hotplug was uncondtionally enabled since it was introduced, consuming IO ports and providing AML regardles of whether it was actually in use or not. Keep it so for 2.6 and older machines.
New machine types will have an option to turn CPU hotplug on if it's needed while by default it stays disabled not consuming extra RAM/IO resources.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
What if people are using "-machine pc -smp N,max_cpus=M"? Shouldn't we at least warning about missing CPU hotplug support when using just "max_cpus" with no "cpu-hotplug=on" with pc-2.7 and newer? Yep, I'll add it on next respin. Would hard error better than warning?
Not sure. It would break older libvirt versions, wouldn't it? But: isn't the new legacy-cpu-hotplug=false default going to break old libvirt versions anyway? Should we? (CCing libvirt list)
Should max_cpus > smp_cpus automatically set cpu-hotplug=on? I'd prefer dumb explicit feature enablement, as it doesn't put any assumptions on other options and QEMU + mgmt don't have to maintain logic for implicit rules that might enable it.
and if I didn't manage to push 'device_add x86cpu' in 2.7 time frame, guess work gets a bit confusing with current cpu-add semantic, consider current:
SRC-QEMU -smp 1,maxcpus=2 cpu-add 1 DST-QEMU -smp 2,maxcpus=2
vs would be device_add:
SRC-QEMU -smp 1,maxcpus=2 device_add cpu DST-QEMU -smp 1,maxcpus=2 -device cpu
so instead of qemu/users guessing, I suggest to make it explictly enabled to get feature (which is mostly optional) or cleanly fail qemu start if confusing options are specified with a clear error message.
Agreed we shouldn't encourage people to use the old option to get the new behavior. But I am worried about breaking existing configurations on a machine-type change. Is it possible to avoid that? -- Eduardo
On Wed, May 11, 2016 at 08:36:00PM -0300, Eduardo Habkost wrote:
On Wed, May 11, 2016 at 03:50:39PM +0200, Igor Mammedov wrote:
On Tue, 10 May 2016 17:24:14 -0300 Eduardo Habkost <ehabkost@redhat.com> wrote:
On Mon, May 02, 2016 at 02:33:21PM +0200, Igor Mammedov wrote:
on old machine types CPU hotplug was uncondtionally enabled since it was introduced, consuming IO ports and providing AML regardles of whether it was actually in use or not. Keep it so for 2.6 and older machines.
New machine types will have an option to turn CPU hotplug on if it's needed while by default it stays disabled not consuming extra RAM/IO resources.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
What if people are using "-machine pc -smp N,max_cpus=M"? Shouldn't we at least warning about missing CPU hotplug support when using just "max_cpus" with no "cpu-hotplug=on" with pc-2.7 and newer? Yep, I'll add it on next respin. Would hard error better than warning?
Not sure. It would break older libvirt versions, wouldn't it? But: isn't the new legacy-cpu-hotplug=false default going to break old libvirt versions anyway? Should we?
(CCing libvirt list)
Even if not, we should not break scripts people use. Maybe it was a mistake to enable hotplug by default but we can't just remove it now after all this time. Why not have new hotplug on by default as well? If you see value in ability to remove this feature, add an option for that.
Should max_cpus > smp_cpus automatically set cpu-hotplug=on? I'd prefer dumb explicit feature enablement, as it doesn't put any assumptions on other options and QEMU + mgmt don't have to maintain logic for implicit rules that might enable it.
and if I didn't manage to push 'device_add x86cpu' in 2.7 time frame, guess work gets a bit confusing with current cpu-add semantic, consider current:
SRC-QEMU -smp 1,maxcpus=2 cpu-add 1 DST-QEMU -smp 2,maxcpus=2
vs would be device_add:
SRC-QEMU -smp 1,maxcpus=2 device_add cpu DST-QEMU -smp 1,maxcpus=2 -device cpu
so instead of qemu/users guessing, I suggest to make it explictly enabled to get feature (which is mostly optional) or cleanly fail qemu start if confusing options are specified with a clear error message.
Agreed we shouldn't encourage people to use the old option to get the new behavior.
But I am worried about breaking existing configurations on a machine-type change. Is it possible to avoid that?
-- Eduardo
On Thu, 12 May 2016 10:05:54 +0300 "Michael S. Tsirkin" <mst@redhat.com> wrote:
On Wed, May 11, 2016 at 08:36:00PM -0300, Eduardo Habkost wrote:
On Wed, May 11, 2016 at 03:50:39PM +0200, Igor Mammedov wrote:
On Tue, 10 May 2016 17:24:14 -0300 Eduardo Habkost <ehabkost@redhat.com> wrote:
On Mon, May 02, 2016 at 02:33:21PM +0200, Igor Mammedov wrote:
on old machine types CPU hotplug was uncondtionally enabled since it was introduced, consuming IO ports and providing AML regardles of whether it was actually in use or not. Keep it so for 2.6 and older machines.
New machine types will have an option to turn CPU hotplug on if it's needed while by default it stays disabled not consuming extra RAM/IO resources.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
What if people are using "-machine pc -smp N,max_cpus=M"? Shouldn't we at least warning about missing CPU hotplug support when using just "max_cpus" with no "cpu-hotplug=on" with pc-2.7 and newer? Yep, I'll add it on next respin. Would hard error better than warning?
Not sure. It would break older libvirt versions, wouldn't it? But: isn't the new legacy-cpu-hotplug=false default going to break old libvirt versions anyway? Should we? if older libvirt are running older machine version, it won't break it. but it would break old libvirt for new machine types.
(CCing libvirt list)
Even if not, we should not break scripts people use. Maybe it was a mistake to enable hotplug by default but we can't just remove it now after all this time. Why not have new hotplug on by default as well? If you see value in ability to remove this feature, add an option for that. It would save us some space in ACPI tables and IO ports as by default it's not used feature.
But if it's preferred to keep cpu-hotplug always on, I'm ok with it too, it's even better as I would be able to drop 3-4 patches from this series.
Should max_cpus > smp_cpus automatically set cpu-hotplug=on? I'd prefer dumb explicit feature enablement, as it doesn't put any assumptions on other options and QEMU + mgmt don't have to maintain logic for implicit rules that might enable it.
and if I didn't manage to push 'device_add x86cpu' in 2.7 time frame, guess work gets a bit confusing with current cpu-add semantic, consider current:
SRC-QEMU -smp 1,maxcpus=2 cpu-add 1 DST-QEMU -smp 2,maxcpus=2
vs would be device_add:
SRC-QEMU -smp 1,maxcpus=2 device_add cpu DST-QEMU -smp 1,maxcpus=2 -device cpu
so instead of qemu/users guessing, I suggest to make it explictly enabled to get feature (which is mostly optional) or cleanly fail qemu start if confusing options are specified with a clear error message.
Agreed we shouldn't encourage people to use the old option to get the new behavior.
But I am worried about breaking existing configurations on a machine-type change. Is it possible to avoid that?
-- Eduardo
participants (3)
-
Eduardo Habkost -
Igor Mammedov -
Michael S. Tsirkin