From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] cpu hotplug issue Date: Wed, 03 Aug 2011 12:37:13 +0200 Message-ID: <4E3924D9.7000302@siemens.com> References: <20110721124512.GI3044@redhat.com> <4E29577A.9080909@siemens.com> <20110724115647.GR3044@redhat.com> <4E2C4434.1060106@web.de> <4E2D6D1B.8020903@siemens.com> <4E3193B9.5040407@siemens.com> <4E37D053.1050106@siemens.com> <20110803100702.GC19574@dhcp-192-168-178-175.profitbricks.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "seabios@seabios.org" , "kvm@vger.kernel.org" , "gleb@redhat.com" , "armbru@redhat.com" To: Vasilis Liaskovitis Return-path: Received: from david.siemens.de ([192.35.17.14]:31734 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753872Ab1HCKhV (ORCPT ); Wed, 3 Aug 2011 06:37:21 -0400 In-Reply-To: <20110803100702.GC19574@dhcp-192-168-178-175.profitbricks.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-08-03 12:07, Vasilis Liaskovitis wrote: > When rebooting after a CPU hotplug in qemu-kvm, Seabios can get stuck in smp_probe(). > Normally cmos_smp_count is read from cmos and the smp_ap_boot_code is run on all cpus > except bootstrap. The expected result is CountCPUs == cmos_smp_count + 1. After a > cpu hotplug, more than cmos_smp_count cpus are active, so we get a situation where > CountCPUs > cmos_smp_count + 1 and Seabios keeps looping forever in smp_probe. In some > cases, the while loop exit condition is tested before CountCPUs gets larger (i.e. > before smp_ap_boot_code runs on all CPUs), so the hang is not always reproducible. > > This patch introduces a new fw_cfg variable called hotplugged_cpus that gets updated from > qemu-kvm hoplug code. Seabios reads this variable on each call to smp_probe() and adjusts > the expected number of online CPUs. > > The qemu-kvm part of this patch is against Jan Kiszka's cpu-hotplug tree: > git://git.kiszka.org/qemu-kvm.git queues/cpu-hotplug > tested with qemu-system-x86_64. > > An alternative to this patch would be to update the smp_cpus variable in qemu-kvm and > do a "cmos update" to 0x5f from the cpu-hotplug code. Access to the rtc_state (cmos device) > would be required in hw/acpi_piix4.c. This way no change to Seabios would be required. > ... > src/paravirt.c | 12 ++++++++++++ > src/paravirt.h | 2 ++ > src/smp.c | 6 ++++-- > 3 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/src/paravirt.c b/src/paravirt.c > index 9cf77de..3367609 100644 > --- a/src/paravirt.c > +++ b/src/paravirt.c > @@ -305,6 +305,18 @@ u16 qemu_cfg_get_max_cpus(void) > return cnt; > } > > +u16 qemu_cfg_get_hplug_cpus(void) > +{ > + u16 cnt; > + > + if (!qemu_cfg_present) > + return 0; > + > + qemu_cfg_read_entry(&cnt, QEMU_CFG_HPLUG_CPUS, sizeof(cnt)); Why can't Seabios read to true number online CPUs from the PIIX4 device? The information is there already, no need for addition PV here. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux