mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-03 15:53:54 -06:00
* s390x CPU topology support
* Simplify the KVM register synchronization code * Disable the analyze-migration.py test on s390x -----BEGIN PGP SIGNATURE----- iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmUyDYMRHHRodXRoQHJl ZGhhdC5jb20ACgkQLtnXdP5wLbUlgBAAkF3dvW0vMcb653sCI5vt2GHIvQQtc2Rw ghRRcTBZ7wyVxKHtqohCh7/byzDW5YEuCWUyLsc2oIz/84pc00VR/5Ng1EAxLAfe mvzzjr4jX96SmoO0DbJpqJQXaUPNYdmoshbRL0I3wkIfGtkvGRM8zHZuYINOg0hw bH6gWZ2QL/NFjXh0uAOaJB1+hRtPWvHD2rnVt0g9U9W5QhRxGJqti5YEaLBH7hh5 RydsquRZ/E6uFw4pMjjvCxDaswPwejddrP2YeR5Fd5Zo+Kzp53r9Hf/eJwlZ8yFL 5f1dRb19NZYpW1hZuJVOP8tkPydYxAM85vkUunI7Qg4gez5KI0Nz6hQozw6ufMlQ r8L17fwQMsCrwcRypImYNXyyrtHlNH5Y8FjqTct8aK64Bw3e7Qqi7d3ybFAuYZ+D k2EJ8Rlwhbg69h+Q+ucHx4NkYu9+2MFS6G7w5EcM6xl3WHSwUxh9orlEMsIkyHS3 OMFMTr1jjfFdEN6EafhPwFE/xKglFF2Fe3u6NoR+5pkv3UA5Z87giitxoekYecpH J96P3anORpWW75qvOF+nccqrd7OrUL1/yYdOyJh5Tkm0oCIeQ9E5extVf3Gne3E/ yWzr00GJRiHFO2qbGStgKHTQLItgQpccwNpSzEdgHCqwLbXl6e3Hoq42VIFOlbN/ ZtgpyUkuYyQ= =xDb+ -----END PGP SIGNATURE----- Merge tag 'pull-request-2023-10-20' of https://gitlab.com/thuth/qemu into staging * s390x CPU topology support * Simplify the KVM register synchronization code * Disable the analyze-migration.py test on s390x # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmUyDYMRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbUlgBAAkF3dvW0vMcb653sCI5vt2GHIvQQtc2Rw # ghRRcTBZ7wyVxKHtqohCh7/byzDW5YEuCWUyLsc2oIz/84pc00VR/5Ng1EAxLAfe # mvzzjr4jX96SmoO0DbJpqJQXaUPNYdmoshbRL0I3wkIfGtkvGRM8zHZuYINOg0hw # bH6gWZ2QL/NFjXh0uAOaJB1+hRtPWvHD2rnVt0g9U9W5QhRxGJqti5YEaLBH7hh5 # RydsquRZ/E6uFw4pMjjvCxDaswPwejddrP2YeR5Fd5Zo+Kzp53r9Hf/eJwlZ8yFL # 5f1dRb19NZYpW1hZuJVOP8tkPydYxAM85vkUunI7Qg4gez5KI0Nz6hQozw6ufMlQ # r8L17fwQMsCrwcRypImYNXyyrtHlNH5Y8FjqTct8aK64Bw3e7Qqi7d3ybFAuYZ+D # k2EJ8Rlwhbg69h+Q+ucHx4NkYu9+2MFS6G7w5EcM6xl3WHSwUxh9orlEMsIkyHS3 # OMFMTr1jjfFdEN6EafhPwFE/xKglFF2Fe3u6NoR+5pkv3UA5Z87giitxoekYecpH # J96P3anORpWW75qvOF+nccqrd7OrUL1/yYdOyJh5Tkm0oCIeQ9E5extVf3Gne3E/ # yWzr00GJRiHFO2qbGStgKHTQLItgQpccwNpSzEdgHCqwLbXl6e3Hoq42VIFOlbN/ # ZtgpyUkuYyQ= # =xDb+ # -----END PGP SIGNATURE----- # gpg: Signature made Thu 19 Oct 2023 22:17:55 PDT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2023-10-20' of https://gitlab.com/thuth/qemu: (24 commits) tests/qtest/migration-test: Disable the analyze-migration.py test on s390x target/s390x/kvm: Simplify the GPRs, ACRs, CRs and prefix synchronization code target/s390x/kvm: Turn KVM_CAP_SYNC_REGS into a hard requirement tests/avocado: s390x cpu topology bad move tests/avocado: s390x cpu topology dedicated errors tests/avocado: s390x cpu topology test socket full tests/avocado: s390x cpu topology test dedicated CPU tests/avocado: s390x cpu topology entitlement tests tests/avocado: s390x cpu topology polarization tests/avocado: s390x cpu topology core docs/s390x/cpu topology: document s390x cpu topology qapi/s390x/cpu topology: add query-s390x-cpu-polarization command qapi/s390x/cpu topology: CPU_POLARIZATION_CHANGE QAPI event machine: adding s390 topology to info hotpluggable-cpus machine: adding s390 topology to query-cpu-fast qapi/s390x/cpu topology: set-cpu-topology qmp command target/s390x/cpu topology: activate CPU topology s390x/cpu topology: interception of PTF instruction s390x/cpu topology: resetting the Topology-Change-Report s390x/sclp: reporting the maximum nested topology entries ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This commit is contained in:
commit
ebdf417220
35 changed files with 2288 additions and 128 deletions
244
docs/system/s390x/cpu-topology.rst
Normal file
244
docs/system/s390x/cpu-topology.rst
Normal file
|
@ -0,0 +1,244 @@
|
|||
.. _cpu-topology-s390x:
|
||||
|
||||
CPU topology on s390x
|
||||
=====================
|
||||
|
||||
Since QEMU 8.2, CPU topology on s390x provides up to 3 levels of
|
||||
topology containers: drawers, books and sockets. They define a
|
||||
tree-shaped hierarchy.
|
||||
|
||||
The socket container has one or more CPU entries.
|
||||
Each of these CPU entries consists of a bitmap and three CPU attributes:
|
||||
|
||||
- CPU type
|
||||
- entitlement
|
||||
- dedication
|
||||
|
||||
Each bit set in the bitmap correspond to a core-id of a vCPU with matching
|
||||
attributes.
|
||||
|
||||
This documentation provides general information on S390 CPU topology,
|
||||
how to enable it and explains the new CPU attributes.
|
||||
For information on how to modify the S390 CPU topology and how to
|
||||
monitor polarization changes, see ``docs/devel/s390-cpu-topology.rst``.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
To use the CPU topology, you need to run with KVM on a s390x host that
|
||||
uses the Linux kernel v6.0 or newer (which provide the so-called
|
||||
``KVM_CAP_S390_CPU_TOPOLOGY`` capability that allows QEMU to signal the
|
||||
CPU topology facility via the so-called STFLE bit 11 to the VM).
|
||||
|
||||
Enabling CPU topology
|
||||
---------------------
|
||||
|
||||
Currently, CPU topology is only enabled in the host model by default.
|
||||
|
||||
Enabling CPU topology in a CPU model is done by setting the CPU flag
|
||||
``ctop`` to ``on`` as in:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-cpu gen16b,ctop=on
|
||||
|
||||
Having the topology disabled by default allows migration between
|
||||
old and new QEMU without adding new flags.
|
||||
|
||||
Default topology usage
|
||||
----------------------
|
||||
|
||||
The CPU topology can be specified on the QEMU command line
|
||||
with the ``-smp`` or the ``-device`` QEMU command arguments.
|
||||
|
||||
Note also that since 7.2 threads are no longer supported in the topology
|
||||
and the ``-smp`` command line argument accepts only ``threads=1``.
|
||||
|
||||
If none of the containers attributes (drawers, books, sockets) are
|
||||
specified for the ``-smp`` flag, the number of these containers
|
||||
is 1.
|
||||
|
||||
Thus the following two options will result in the same topology:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-smp cpus=5,drawer=1,books=1,sockets=8,cores=4,maxcpus=32
|
||||
|
||||
and
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-smp cpus=5,sockets=8,cores=4,maxcpus=32
|
||||
|
||||
When a CPU is defined by the ``-smp`` command argument, its position
|
||||
inside the topology is calculated by adding the CPUs to the topology
|
||||
based on the core-id starting with core-0 at position 0 of socket-0,
|
||||
book-0, drawer-0 and filling all CPUs of socket-0 before filling socket-1
|
||||
of book-0 and so on up to the last socket of the last book of the last
|
||||
drawer.
|
||||
|
||||
When a CPU is defined by the ``-device`` command argument, the
|
||||
tree topology attributes must all be defined or all not defined.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-device gen16b-s390x-cpu,drawer-id=1,book-id=1,socket-id=2,core-id=1
|
||||
|
||||
or
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
-device gen16b-s390x-cpu,core-id=1,dedicated=true
|
||||
|
||||
If none of the tree attributes (drawer, book, sockets), are specified
|
||||
for the ``-device`` argument, like for all CPUs defined with the ``-smp``
|
||||
command argument the topology tree attributes will be set by simply
|
||||
adding the CPUs to the topology based on the core-id.
|
||||
|
||||
QEMU will not try to resolve collisions and will report an error if the
|
||||
CPU topology defined explicitly or implicitly on a ``-device``
|
||||
argument collides with the definition of a CPU implicitly defined
|
||||
on the ``-smp`` argument.
|
||||
|
||||
When the topology modifier attributes are not defined for the
|
||||
``-device`` command argument they takes following default values:
|
||||
|
||||
- dedicated: ``false``
|
||||
- entitlement: ``medium``
|
||||
|
||||
|
||||
Hot plug
|
||||
++++++++
|
||||
|
||||
New CPUs can be plugged using the device_add hmp command as in:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
(qemu) device_add gen16b-s390x-cpu,core-id=9
|
||||
|
||||
The placement of the CPU is derived from the core-id as described above.
|
||||
|
||||
The topology can of course also be fully defined:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
(qemu) device_add gen16b-s390x-cpu,drawer-id=1,book-id=1,socket-id=2,core-id=1
|
||||
|
||||
|
||||
Examples
|
||||
++++++++
|
||||
|
||||
In the following machine we define 8 sockets with 4 cores each.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ qemu-system-s390x -m 2G \
|
||||
-cpu gen16b,ctop=on \
|
||||
-smp cpus=5,sockets=8,cores=4,maxcpus=32 \
|
||||
-device host-s390x-cpu,core-id=14 \
|
||||
|
||||
A new CPUs can be plugged using the device_add hmp command as before:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
(qemu) device_add gen16b-s390x-cpu,core-id=9
|
||||
|
||||
The core-id defines the placement of the core in the topology by
|
||||
starting with core 0 in socket 0 up to maxcpus.
|
||||
|
||||
In the example above:
|
||||
|
||||
* There are 5 CPUs provided to the guest with the ``-smp`` command line
|
||||
They will take the core-ids 0,1,2,3,4
|
||||
As we have 4 cores in a socket, we have 4 CPUs provided
|
||||
to the guest in socket 0, with core-ids 0,1,2,3.
|
||||
The last CPU, with core-id 4, will be on socket 1.
|
||||
|
||||
* the core with ID 14 provided by the ``-device`` command line will
|
||||
be placed in socket 3, with core-id 14
|
||||
|
||||
* the core with ID 9 provided by the ``device_add`` qmp command will
|
||||
be placed in socket 2, with core-id 9
|
||||
|
||||
|
||||
Polarization, entitlement and dedication
|
||||
----------------------------------------
|
||||
|
||||
Polarization
|
||||
++++++++++++
|
||||
|
||||
The polarization affects how the CPUs of a shared host are utilized/distributed
|
||||
among guests.
|
||||
The guest determines the polarization by using the PTF instruction.
|
||||
|
||||
Polarization defines two models of CPU provisioning: horizontal
|
||||
and vertical.
|
||||
|
||||
The horizontal polarization is the default model on boot and after
|
||||
subsystem reset. When horizontal polarization is in effect all vCPUs should
|
||||
have about equal resource provisioning.
|
||||
|
||||
In the vertical polarization model vCPUs are unequal, but overall more resources
|
||||
might be available.
|
||||
The guest can make use of the vCPU entitlement information provided by the host
|
||||
to optimize kernel thread scheduling.
|
||||
|
||||
A subsystem reset puts all vCPU of the configuration into the
|
||||
horizontal polarization.
|
||||
|
||||
Entitlement
|
||||
+++++++++++
|
||||
|
||||
The vertical polarization specifies that the guest's vCPU can get
|
||||
different real CPU provisioning:
|
||||
|
||||
- a vCPU with vertical high entitlement specifies that this
|
||||
vCPU gets 100% of the real CPU provisioning.
|
||||
|
||||
- a vCPU with vertical medium entitlement specifies that this
|
||||
vCPU shares the real CPU with other vCPUs.
|
||||
|
||||
- a vCPU with vertical low entitlement specifies that this
|
||||
vCPU only gets real CPU provisioning when no other vCPUs needs it.
|
||||
|
||||
In the case a vCPU with vertical high entitlement does not use
|
||||
the real CPU, the unused "slack" can be dispatched to other vCPU
|
||||
with medium or low entitlement.
|
||||
|
||||
A vCPU can be "dedicated" in which case the vCPU is fully dedicated to a single
|
||||
real CPU.
|
||||
|
||||
The dedicated bit is an indication of affinity of a vCPU for a real CPU
|
||||
while the entitlement indicates the sharing or exclusivity of use.
|
||||
|
||||
Defining the topology on the command line
|
||||
-----------------------------------------
|
||||
|
||||
The topology can entirely be defined using -device cpu statements,
|
||||
with the exception of CPU 0 which must be defined with the -smp
|
||||
argument.
|
||||
|
||||
For example, here we set the position of the cores 1,2,3 to
|
||||
drawer 1, book 1, socket 2 and cores 0,9 and 14 to drawer 0,
|
||||
book 0, socket 0 without defining entitlement or dedication.
|
||||
Core 4 will be set on its default position on socket 1
|
||||
(since we have 4 core per socket) and we define it as dedicated and
|
||||
with vertical high entitlement.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ qemu-system-s390x -m 2G \
|
||||
-cpu gen16b,ctop=on \
|
||||
-smp cpus=1,sockets=8,cores=4,maxcpus=32 \
|
||||
\
|
||||
-device gen16b-s390x-cpu,drawer-id=1,book-id=1,socket-id=2,core-id=1 \
|
||||
-device gen16b-s390x-cpu,drawer-id=1,book-id=1,socket-id=2,core-id=2 \
|
||||
-device gen16b-s390x-cpu,drawer-id=1,book-id=1,socket-id=2,core-id=3 \
|
||||
\
|
||||
-device gen16b-s390x-cpu,drawer-id=0,book-id=0,socket-id=0,core-id=9 \
|
||||
-device gen16b-s390x-cpu,drawer-id=0,book-id=0,socket-id=0,core-id=14 \
|
||||
\
|
||||
-device gen16b-s390x-cpu,core-id=4,dedicated=on,entitlement=high
|
||||
|
||||
The entitlement defined for the CPU 4 will only be used after the guest
|
||||
successfully enables vertical polarization by using the PTF instruction.
|
|
@ -34,3 +34,4 @@ Architectural features
|
|||
.. toctree::
|
||||
s390x/bootdevices
|
||||
s390x/protvirt
|
||||
s390x/cpu-topology
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue