From: Igor Mammedov <imammedo@redhat.com>
To: qemu-devel@nongnu.org
Cc: ehabkost@redhat.com, marcel.apfelbaum@gmail.com, mst@redhat.com
Subject: [Qemu-devel] [PATCH v3 0/8] pc: do not create invalid MADT.LAPIC/Processor entries
Date: Tue, 23 Feb 2016 17:05:52 +0100 [thread overview]
Message-ID: <1456243560-67516-1-git-send-email-imammedo@redhat.com> (raw)
Changes since v2:
- build possible CPUs list only once.
Marcel Apfelbaum <marcel@redhat.com>
- replace MachineClass possible_cpu_arch_ids() hook with
QOM interface, so only targets that need it would implement it
- fix ^2 times present CPU lookup for initial CPUs
Eduardo Habkost <ehabkost@redhat.com>
- drop found_cpus bitmap altogether
Changes since v1:
- rebased on top of PCI tree that contains
Eduardo's guest_info removel series
- fix ^2 times present CPU lookup when creating CPON
package (spotted-by: Eduardo Habkost <ehabkost@redhat.com>)
It's mostly clean up series that removes invalid CPU
entries from MADT/DSDT/SRAT tables when APIC IDs are
sparse distributed*.
Series also removes intermediate present CPUs bitmap
in ACPI tables generation code, replacing it with
machine reported presence status. That should
help later for consolidating and sharing CPU hotplug
codebase and extending supported CPU count above 256
on ACPI side, where I'm going to replace current
"not scalable" bitmap based CPU hotplug MMIO interface
with memory-hotplug like one, which could easily
scale and provide additional info for ACPI CPU device
objects.
Tested hoptlug with: RHEL72 and WS2003 / WS2012R2.
Git tree for testing:
https://github.com/imammedo/qemu.git pc_madt_dsdt_lapic_cleanups_v3
* example topology with sparse APIC IDs:
-smp X,sockets=2,cores=3,maxcpus=6
* it's not possible to remove notion of apic_ad_limit
since guest visible interfaces like CPU hoptlug MMIO
(CPON array in ACPI + corresponding MMIO in QEMU) and
FWCFG should stay the same for compat reasons with
current setups and legacy SeaBIOS.
Igor Mammedov (8):
pc: init pcms->apic_id_limit once and use it throughout pc.c
cpu: introduce possible-cpus interface
pc: acpi: cleanup qdev_get_machine() calls
pc: acpi: SRAT: create only valid processor lapic entries
pc: acpi: create MADT.lapic entries only for valid lapics
pc: acpi: create Processor and Notify objects only for valid lapics
pc: acpi: drop cpu->found_cpus bitmap
pc: acpi: clarify why possible LAPIC entries must be present in MADT
hw/i386/acpi-build.c | 150 ++++++++++++++++++++++++++-------------------------
hw/i386/pc.c | 91 ++++++++++++++++++++-----------
include/hw/boards.h | 1 +
include/hw/i386/pc.h | 1 +
include/qom/cpu.h | 47 ++++++++++++++++
qom/cpu.c | 7 +++
6 files changed, 193 insertions(+), 104 deletions(-)
--
1.8.3.1
next reply other threads:[~2016-02-23 16:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 16:05 Igor Mammedov [this message]
2016-02-23 16:05 ` [Qemu-devel] [PATCH v3 1/8] pc: init pcms->apic_id_limit once and use it throughout pc.c Igor Mammedov
2016-02-23 16:05 ` [Qemu-devel] [PATCH v3 2/8] cpu: introduce possible-cpus interface Igor Mammedov
2016-02-23 21:38 ` Eduardo Habkost
2016-02-24 8:36 ` Igor Mammedov
2016-02-23 16:05 ` [Qemu-devel] [PATCH v3 3/8] pc: acpi: cleanup qdev_get_machine() calls Igor Mammedov
2016-02-23 16:05 ` [Qemu-devel] [PATCH v3 4/8] pc: acpi: SRAT: create only valid processor lapic entries Igor Mammedov
2016-02-23 16:05 ` [Qemu-devel] [PATCH v3 5/8] pc: acpi: create MADT.lapic entries only for valid lapics Igor Mammedov
2016-02-23 16:05 ` [Qemu-devel] [PATCH v3 6/8] pc: acpi: create Processor and Notify objects " Igor Mammedov
2016-02-23 16:05 ` [Qemu-devel] [PATCH v3 7/8] pc: acpi: drop cpu->found_cpus bitmap Igor Mammedov
2016-02-23 16:06 ` [Qemu-devel] [PATCH v3 8/8] pc: acpi: clarify why possible LAPIC entries must be present in MADT Igor Mammedov
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=1456243560-67516-1-git-send-email-imammedo@redhat.com \
--to=imammedo@redhat.com \
--cc=ehabkost@redhat.com \
--cc=marcel.apfelbaum@gmail.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 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).