From: Igor Mammedov <imammedo@redhat.com>
To: Ani Sinha <ani@anisinha.ca>
Cc: Eric DeVolder <eric.devolder@oracle.com>,
shannon.zhaosl@gmail.com, mst@redhat.com,
peter.maydell@linaro.org, qemu-arm@nongnu.org,
qemu-devel@nongnu.org, marcel.apfelbaum@gmail.com,
pbonzini@redhat.com, richard.henderson@linaro.org,
eduardo@habkost.net, boris.ostrovsky@oracle.com
Subject: Re: [PATCH v2 3/4] hw/acpi: i386: bump MADT to revision 5
Date: Thu, 20 Apr 2023 16:10:20 +0200 [thread overview]
Message-ID: <20230420161020.7b86d62f@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <CAARzgwwVAptvsR1_8ttUKroLuqKdLc1dHWtNe7S0S3N-Nq4otw@mail.gmail.com>
On Thu, 20 Apr 2023 13:35:58 +0530
Ani Sinha <ani@anisinha.ca> wrote:
> On Tue, Apr 18, 2023 at 10:22 PM Eric DeVolder <eric.devolder@oracle.com> wrote:
> >
> > Currently i386 QEMU generates MADT revision 3, and reports
> > MADT revision 1. ACPI 6.3 introduces MADT revision 5.
> >
> > For MADT revision 4, that introduces ARM GIC structures, which do
> > not apply to i386.
> >
> > For MADT revision 5, the Local APIC flags introduces the Online
> > Capable bitfield.
> >
> > Making MADT generate and report revision 5 will solve problems with
> > CPU hotplug (the Online Capable flag indicates hotpluggable CPUs).
> >
> > Link: https://lore.kernel.org/linux-acpi/20230327191026.3454-1-eric.devolder@oracle.com/T/#t
> > Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
> > ---
> > hw/i386/acpi-common.c | 13 ++++++++++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/i386/acpi-common.c b/hw/i386/acpi-common.c
> > index 52e5c1439a..286c1c5c32 100644
> > --- a/hw/i386/acpi-common.c
> > +++ b/hw/i386/acpi-common.c
> > @@ -38,8 +38,15 @@ void pc_madt_cpu_entry(int uid, const CPUArchIdList *apic_ids,
> > {
> > uint32_t apic_id = apic_ids->cpus[uid].arch_id;
> > /* Flags – Local APIC Flags */
> > - uint32_t flags = apic_ids->cpus[uid].cpu != NULL || force_enabled ?
> > - 1 /* Enabled */ : 0;
> > + bool enabled = apic_ids->cpus[uid].cpu != NULL || force_enabled ?
> > + true : false;
>
> how about "processor_enabled" instead of just "enabled" as the variable name.
>
> > + /*
> > + * ACPI 6.3 5.2.12.2 Local APIC Flags: OnlineCapable must be 0
> > + * if Enabled is set.
> > + */
> > + bool onlinecapable = enabled ? false : true;
>
> ugh, how about uint32 onlinecapable = enabled? 0x0 : 0x2 ?
>
> > + uint32_t flags = onlinecapable ? 0x2 : 0x0 | /* Online Capable */
> > + enabled ? 0x1 : 0x0; /* Enabled */
>
> then here, flags = onlinecapable | processor_enabled? 0x1 : 0x0;
onlinecapable is unnecessary complication.
See my reply on v1, we don't really have a reason to bump MADT revision to 5,
It brings no value whatsoever. (and kernel fix went another route instead of
dealing with messed up MADT revision numbering in spec)
All we need is to just bump revision to 3 or 4 to match actually
used features.
>
> >
> > /* ACPI spec says that LAPIC entry for non present
> > * CPU may be omitted from MADT or it must be marked
> > @@ -102,7 +109,7 @@ void acpi_build_madt(GArray *table_data, BIOSLinker *linker,
> > MachineClass *mc = MACHINE_GET_CLASS(x86ms);
> > const CPUArchIdList *apic_ids = mc->possible_cpu_arch_ids(MACHINE(x86ms));
> > AcpiDeviceIfClass *adevc = ACPI_DEVICE_IF_GET_CLASS(adev);
> > - AcpiTable table = { .sig = "APIC", .rev = 1, .oem_id = oem_id,
> > + AcpiTable table = { .sig = "APIC", .rev = 5, .oem_id = oem_id,
> > .oem_table_id = oem_table_id };
> >
> > acpi_table_begin(&table, table_data);
> > --
> > 2.31.1
> >
>
next prev parent reply other threads:[~2023-04-20 14:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 16:52 [PATCH v2 0/4] hw/acpi: bump MADT to revision 5 Eric DeVolder
2023-04-18 16:52 ` [PATCH v2 1/4] ACPI: bios-tables-test.c step 2 (allowed-diff entries) Eric DeVolder
2023-04-18 16:52 ` [PATCH v2 2/4] hw/acpi: arm: bump MADT to revision 5 Eric DeVolder
2023-04-19 5:30 ` Michael S. Tsirkin
2023-04-19 14:04 ` Eric DeVolder
2023-04-18 16:52 ` [PATCH v2 3/4] hw/acpi: i386: " Eric DeVolder
2023-04-19 14:56 ` Michael S. Tsirkin
2023-04-19 14:59 ` Eric DeVolder
2023-04-20 8:05 ` Ani Sinha
2023-04-20 14:10 ` Igor Mammedov [this message]
2023-04-20 14:22 ` Eric DeVolder
2023-04-21 8:15 ` Michael S. Tsirkin
2023-04-18 16:52 ` [PATCH v2 4/4] ACPI: bios-tables-test.c step 5 (updated expected table binaries) Eric DeVolder
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=20230420161020.7b86d62f@imammedo.users.ipa.redhat.com \
--to=imammedo@redhat.com \
--cc=ani@anisinha.ca \
--cc=boris.ostrovsky@oracle.com \
--cc=eduardo@habkost.net \
--cc=eric.devolder@oracle.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=shannon.zhaosl@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).