From: Laszlo Ersek <lersek@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>, qemu-devel@nongnu.org
Cc: "Igor Mammedov" <imammedo@redhat.com>,
"Andreas Färber" <afaerber@suse.de>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 5/7] pc: Refuse max_cpus if it results in too large APIC ID
Date: Fri, 14 Mar 2014 20:07:19 +0100 [thread overview]
Message-ID: <53235367.2020705@redhat.com> (raw)
In-Reply-To: <1394823137-4369-6-git-send-email-ehabkost@redhat.com>
On 03/14/14 19:52, Eduardo Habkost wrote:
> This changes the PC initialization code to reject max_cpus if it results
> in an APIC ID that's too large, instead of aborting or erroring out when
> it is already too late.
>
> Currently there are two limits we need to check: the CPU hotplug APIC ID
> limit (due to the AcpiCpuHotplug.sts array length), and the
> MAX_CPUMASK_BITS limit (that's used for CPU bitmaps on NUMA code and
> hw/i386/acpi-build.c).
>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> Changes v2 -> v3:
> * No need to check against MAX_CPUMASK_BITS, as MAX_CPUMASK_BITS
> is used only for CPU-index-based bitmaps on NUMA code, not for APIC
> IDs.
> ---
> hw/i386/pc.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 74cb4f9..14f0d91 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -992,6 +992,7 @@ void pc_cpus_init(const char *cpu_model, DeviceState *icc_bridge)
> int i;
> X86CPU *cpu = NULL;
> Error *error = NULL;
> + unsigned long apic_id_limit;
>
> /* init CPUs */
> if (cpu_model == NULL) {
> @@ -1003,6 +1004,13 @@ void pc_cpus_init(const char *cpu_model, DeviceState *icc_bridge)
> }
> current_cpu_model = cpu_model;
>
> + apic_id_limit = pc_apic_id_limit(max_cpus);
> + if (apic_id_limit > ACPI_CPU_HOTPLUG_ID_LIMIT) {
> + error_report("max_cpus is too large. APIC ID of last CPU is %lu",
> + apic_id_limit - 1);
> + exit(1);
> + }
> +
> for (i = 0; i < smp_cpus; i++) {
> cpu = pc_new_cpu(cpu_model, x86_cpu_apic_id_from_index(i),
> icc_bridge, &error);
>
This patch is now good, but you've forgotten to update the commit
message -- the v2->v3 change block (that you've put under the ---
separator) actually contradicts the commit message.
Please repost the patch with the updated commit message -- I think it
suffices to simply drop the second paragraph! --, and feel free to add
my R-b in that v4 posting.
Thanks,
Laszlo
next prev parent reply other threads:[~2014-03-14 19:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 18:52 [Qemu-devel] [PATCH v3 0/7] pc: Ensure APIC ID limits before aborting or corrupting memory Eduardo Habkost
2014-03-14 18:52 ` [Qemu-devel] [PATCH v3 1/7] acpi: Add ACPI_CPU_HOTPLUG_ID_LIMIT macro Eduardo Habkost
2014-03-14 18:52 ` [Qemu-devel] [PATCH v3 2/7] pc: Refuse CPU hotplug if the resulting APIC ID is too large Eduardo Habkost
2014-03-14 18:52 ` [Qemu-devel] [PATCH v3 3/7] acpi: Assert sts array limit on AcpiCpuHotplug_add() Eduardo Habkost
2014-03-14 18:52 ` [Qemu-devel] [PATCH v3 4/7] acpi: Don't use MAX_CPUMASK_BITS for APIC ID bitmap Eduardo Habkost
2014-03-14 19:03 ` Laszlo Ersek
2014-03-14 19:56 ` Laszlo Ersek
2014-03-14 18:52 ` [Qemu-devel] [PATCH v3 5/7] pc: Refuse max_cpus if it results in too large APIC ID Eduardo Habkost
2014-03-14 19:07 ` Laszlo Ersek [this message]
2014-03-14 18:52 ` [Qemu-devel] [PATCH v3 6/7] vl.c: Rename MAX_CPUMASK_BITS to MAX_CPUS Eduardo Habkost
2014-03-14 19:09 ` Laszlo Ersek
2014-03-14 18:52 ` [Qemu-devel] [PATCH v3 7/7] vl.c: Use MAX_CPUS macro instead of hardcoded constant Eduardo Habkost
2014-03-14 19:11 ` Laszlo Ersek
2014-03-14 19:30 ` Eduardo Habkost
2014-03-14 19:38 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53235367.2020705@redhat.com \
--to=lersek@redhat.com \
--cc=afaerber@suse.de \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.