[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
[Qemu-devel] [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1
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<>.
"pc: Ensure non-zero CPU ref count after attaching to ICC bus"
-> this series adding socket/core objects
Available for testing here:
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
- [Qemu-devel] [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1,
Andreas Färber <=
- [Qemu-devel] [PATCH RFC 1/4] cpu: Prepare Socket container type, Andreas Färber, 2015/03/23
- [Qemu-devel] [PATCH RFC 4/4] pc: Create initial CPUs in-place, Andreas Färber, 2015/03/23
- [Qemu-devel] [PATCH RFC 2/4] target-i386: Prepare CPU socket/core abstraction, Andreas Färber, 2015/03/23
- Re: [Qemu-devel] [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1, Christian Borntraeger, 2015/03/24
- Re: [Qemu-devel] [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1, Igor Mammedov, 2015/03/26