qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

             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).