Message-Id: <20220714101824.101601-1-pmorel@linux.ibm.com>
Date:   Thu, 14 Jul 2022 12:18:22 +0200
From:   Pierre Morel <pmorel@...ux.ibm.com>
To:     kvm@...r.kernel.org
Cc:     linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        borntraeger@...ibm.com, frankja@...ux.ibm.com, cohuck@...hat.com,
        david@...hat.com, thuth@...hat.com, imbrenda@...ux.ibm.com,
        hca@...ux.ibm.com, gor@...ux.ibm.com, pmorel@...ux.ibm.com,
        wintera@...ux.ibm.com, seiden@...ux.ibm.com, nrb@...ux.ibm.com,
        scgl@...ux.ibm.com
Subject: [PATCH v13 0/2] s390x: KVM: CPU Topology

Hi all,

The series provides:
1- interception of the STSI instruction forwarding the CPU topology
2- interpretation of the PTF instruction
3- a KVM capability for the userland hypervisor to ask KVM to 
   setup PTF interpretation.
4- KVM ioctl to get and set the MTCR bit of the SCA in order to
   migrate this bit during a migration.


0- Foreword

The S390 CPU topology is reported using two instructions:
- PTF, to get information if the CPU topology did change since last
  PTF instruction or a subsystem reset.
- STSI, to get the topology information, consisting of the topology
  of the CPU inside the sockets, of the sockets inside the books etc.

The PTF(2) instruction report a change if the STSI(15.1.2) instruction
will report a difference with the last STSI(15.1.2) instruction*.
With the SIE interpretation, the PTF(2) instruction will report a
change to the guest if the host sets the SCA.MTCR bit.

*The STSI(15.1.2) instruction reports:
- The cores address within a socket
- The polarization of the cores
- The CPU type of the cores
- If the cores are dedicated or not

We decided to implement the CPU topology for S390 in several steps:

- first we report CPU hotplug

In future development we will provide:

- modification of the CPU mask inside sockets
- handling of shared CPUs
- reporting of the CPU Type
- reporting of the polarization


1- Interception of STSI

To provide Topology information to the guest through the STSI
instruction, we forward STSI with Function Code 15 to the
userland hypervisor which will take care to provide the right
information to the guest.

To let the guest use both the PTF instruction  to check if a topology
change occurred and sthe STSI_15.x.x instruction we add a new KVM
capability to enable the topology facility.

2- Interpretation of PTF with FC(2)

The PTF instruction reports a topology change if there is any change
with a previous STSI(15.1.2) SYSIB.

Changes inside a STSI(15.1.2) SYSIB occur if CPU bits are set or clear
inside the CPU Topology List Entry CPU mask field, which happens with
changes in CPU polarization, dedication, CPU types and adding or
removing CPUs in a socket.

Considering that the KVM guests currently only supports:
- horizontal polarization
- type 3 (Linux) CPU

And that we decide to support only:
- dedicated CPUs on the host
- pinned vCPUs on the guest

the creation of vCPU will is the only trigger to set the MTCR bit for
a guest.

The reporting to the guest is done using the Multiprocessor
Topology-Change-Report (MTCR) bit of the utility entry of the guest's
SCA which will be cleared during the interpretation of PTF.

Regards,
Pierre
Pierre Morel (2):
  KVM: s390: guest support for topology function
  KVM: s390: resetting the Topology-Change-Report

 Documentation/virt/kvm/api.rst   | 25 ++++++++++
 arch/s390/include/asm/kvm_host.h | 18 +++++--
 arch/s390/include/uapi/asm/kvm.h |  1 +
 arch/s390/kvm/kvm-s390.c         | 82 ++++++++++++++++++++++++++++++++
 arch/s390/kvm/priv.c             | 20 ++++++--
 arch/s390/kvm/vsie.c             |  8 ++++
 include/uapi/linux/kvm.h         |  1 +
 7 files changed, 148 insertions(+), 7 deletions(-)

-- 
2.31.1

Changelog:

from v12 to v13

- remove check for protected virtualization
  (Janosch)

- move stting of sca out of the loop
  (Janis)

- Change some function names and typos
  (Janis, Janosch)

from v11 to v12

- protect sca pointer
  (Janis)

- check for user_stsi before returning information
  to userland
  (Janis)

- check for protected virtualization
  (Pierre)

from v10 to v11

- access mctr with interlocked access instead of ipte_lock
  (Janis)

- set mctr in kvm_arch_vcpu_destroy
  (Nico)

- better function documentation
  (Claudio)

- use a single function to set and clear
  (Janosch)

- Use u8 as API data
  (David, Janis)

- Check KVM_CAP_S390_USER_STSI before returning
  data to userspace
  (Nico)

from v9 to v10

- Suppression of the check on real CPU migration
  (Christian)

- Changed the check on fc in handle_stsi
  (David)

from v8 to v9

- bug correction in kvm_s390_topology_changed
  (Heiko)

- simplification for ipte_lock/unlock to use kvm
  as arg instead of vcpu and test on sclp.has_siif
  instead of the SIE ECA_SII.
  (David)

- use of a single value for reporting if the
  topology changed instead of a structure
  (David)

from v7 to v8

- implement reset handling
  (Janosch)

- change the way to check if the topology changed
  (Nico, Heiko)

from v6 to v7

- rebase

from v5 to v6

- make the subject more accurate
  (Claudio)

- Change the kvm_s390_set_mtcr() function to have vcpu in the name
  (Janosch)

- Replace the checks on ECB_PTF wit the check of facility 11
  (Janosch)

- modify kvm_arch_vcpu_load, move the check in a function in
  the header file
  (Janosh)

- No magical number replace the "new cpu value" of -1 with a define
  (Janosch)

- Make the checks for STSI validity clearer
  (Janosch)

from v4 tp v5

- modify the way KVM_CAP is tested to be OK with vsie
  (David)

from v3 to v4

- squatch both patches
  (David)

- Added Documentation
  (David)

- Modified the detection for new vCPUs
  (Pierre)

from v2 to v3

- use PTF interpretation
  (Christian)

- optimize arch_update_cpu_topology using PTF
  (Pierre)

from v1 to v2:

- Add a KVM capability to let QEMU know we support PTF and STSI 15
  (David)

- check KVM facility 11 before accepting STSI fc 15
  (David)

- handle all we can in userland
  (David)

- add tracing to STSI fc 15
  (Connie)

Powered by blists - more mailing lists