[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling

From: Andreas Färber
Subject: [Qemu-devel] [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1
Date: Mon, 23 Mar 2015 18:31:59 +0100


This long-postponed series proposes a hierarchical QOM model of socket
and core objects for the x86 PC machines.

Background is that due to qdev limitations we had to introduce an ICC bus
to be able to hot-add CPUs and their APICs. By now this limitation could be
resolved via a QOM hotplug handler interface.

However, the QOM hotplug model is associated with having link<> properties.
Given that physically we cannot hot-add hyperthreads but full CPU sockets,
this series prepares the underbelly for having those link properties be of
the new type X86CPUSocket rather than X86CPU.

As final step in this series, the X86CPU allocation model is changed to be
init'ed in-place, as part of an "atomic" socket object. A follow-up will be
to attempt the same in-place allocation model for the APIC; one difficulty
there is that several places do a NULL check for the APIC pointer as quick
way of telling whether an APIC is present or not.

NOT IN THIS SERIES is converting cpu-add to the same socket/core/thread model
and initializing them in-place. The current PoC implementation assumes that
CPUs get added sequentially and that the preceding CPU can be used to obtain
the core via unclean QOM parent accesses.
IIUC that must be changed so that an arbitrary thread added via cpu-add
creates the full socket and core(s). That would work best if indexed link<>
properties could be used. That's an undecided design question of whether
we want to have /machine/cpu-socket[n] or whether it makes sense to integrate
NUMA modeling while at it and rather have /machine/node[n]/socket[m].

Note that this socket modeling is not only PC-specific in the softmmu sense
but also in that not every X86CPU must be on a socket (e.g., Quark X1000).
Therefore it was a concious decision to not label some things target-i386
and to place code in pc.c rather than cpu.c.

Further note that it is ignored here that -smp enforces that AMD CPUs don't
have hyperthreads, i.e. AMD X86CPUs will have only one thread[n] child<>.


   qemu.git master
   "pc: Ensure non-zero CPU ref count after attaching to ICC bus"
-> this series adding socket/core objects
   cpu-add conversion
   APIC cleanups

Available for testing here:
git://github.com/afaerber/qemu-cpu.git qom-cpu-x86-sockets-1.v1


Cc: Eduardo Habkost <address@hidden>
Cc: Igor Mammedov <address@hidden>
Cc: Paolo Bonzini <address@hidden>
Cc: Peter Maydell <address@hidden>
Cc: Bharata B Rao <address@hidden>
Cc: Christian Borntraeger <address@hidden>

Andreas Färber (4):
  cpu: Prepare Socket container type
  target-i386: Prepare CPU socket/core abstraction
  pc: Create sockets and cores for CPUs
  pc: Create initial CPUs in-place

 hw/cpu/Makefile.objs         |  2 +-
 hw/cpu/socket.c              | 21 ++++++++++
 hw/i386/Makefile.objs        |  1 +
 hw/i386/cpu-core.c           | 45 +++++++++++++++++++++
 hw/i386/cpu-socket.c         | 45 +++++++++++++++++++++
 hw/i386/pc.c                 | 95 ++++++++++++++++++++++++++++++++++++++++----
 include/hw/cpu/socket.h      | 14 +++++++
 include/hw/i386/cpu-core.h   | 29 ++++++++++++++
 include/hw/i386/cpu-socket.h | 29 ++++++++++++++
 9 files changed, 272 insertions(+), 9 deletions(-)
 create mode 100644 hw/cpu/socket.c
 create mode 100644 hw/i386/cpu-core.c
 create mode 100644 hw/i386/cpu-socket.c
 create mode 100644 include/hw/cpu/socket.h
 create mode 100644 include/hw/i386/cpu-core.h
 create mode 100644 include/hw/i386/cpu-socket.h


reply via email to

[Prev in Thread] Current Thread [Next in Thread]