Includes a headers update against 5.6-current.

- add missing vcpu reset functionality
 - rstfy some s390 documentation
 - fixes and enhancements
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCAAwFiEEw9DWbcNiT/aowBjO3s9rk8bwL68FAl5XrPASHGNvaHVja0By
 ZWRoYXQuY29tAAoJEN7Pa5PG8C+vbLwP/jCxQfhEbiGFs3M7Xz6FNXmGQ3Zmw2j2
 6YNSK7Qpe9GPYlmU4UyhG83buGX1pTF4YgvmpIlMgm33fGRL7FKVDHCXv8qYRvUF
 QB/SV/YfoFwVSBtE7uiHLg0/5YtvbK7dwZiWA1bKSOUp4NsZJofL2qqQnP2m9ecA
 ZRiJxQ2KJjeQ6rLkPHwVkoTut3Xd55HHdKqEo8BVsq1XFKc7nFpE9o4QpuHbODi8
 CzGxJSpUImmsk39obY5jYbW8xiVm6xkVbp+bXGBHSOoCOCFeXqE7MjnF7xE7xeVF
 ST9Jtd/8dFI4v5qVhhfdy/K6EvUoiZ/aUTF1J2PRzg9nueDzYNdJTVVvC/DgCfQn
 joSVjlvawHKzmVkEWcmj3NxQsT1m9pq77HD3du8miYs48IUmE7qsBmKNp8ToaBSV
 L99EwujOFXfrqyCPnfycZzVFWG48+ppmF43gKhthKk7EuacdB8NPr6ePuDkZf9DM
 l6sfjwRGSvZdmgsenvavk12ug433gO2VNxH4AarWNtXq8ADBCtvgQCtEGZMbV+Js
 dm3uPtVF5RKxoHeuXv7wTgt6TybzPEb0+WSEYEfDyquwKFFAAckFmk6giccusXiA
 umXvXXmIab/xa2VVRRNUS4Rq4mJ+kXFKpXVgdt633ZwWFc9vQMFowzUo99+1BUfi
 JX0Bkb4zFbox
 =zN7w
 -----END PGP SIGNATURE-----

Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20200227' into staging

Includes a headers update against 5.6-current.
- add missing vcpu reset functionality
- rstfy some s390 documentation
- fixes and enhancements

# gpg: Signature made Thu 27 Feb 2020 11:50:08 GMT
# gpg:                using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF
# gpg:                issuer "cohuck@redhat.com"
# gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [marginal]
# gpg:                 aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full]
# gpg:                 aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full]
# gpg:                 aka "Cornelia Huck <cohuck@kernel.org>" [marginal]
# gpg:                 aka "Cornelia Huck <cohuck@redhat.com>" [marginal]
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20200227:
  s390x: Rename and use constants for short PSW address and mask
  docs: rstfy vfio-ap documentation
  docs: rstfy s390 dasd ipl documentation
  s390/sclp: improve special wait psw logic
  s390x: Add missing vcpu reset functions
  linux-headers: update
  target/s390x/translate: Fix RNSBG instruction

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

MAINTAINERS

@@ -1259,7 +1259,7 @@ S: Supported
 F: hw/s390x/ipl.*
 F: pc-bios/s390-ccw/
 F: pc-bios/s390-ccw.img
-F: docs/devel/s390-dasd-ipl.txt
+F: docs/devel/s390-dasd-ipl.rst
 T: git https://github.com/borntraeger/qemu.git s390-next
 L: qemu-s390x@nongnu.org
 
@@ -1570,7 +1570,7 @@ F: hw/s390x/ap-bridge.c
 F: include/hw/s390x/ap-device.h
 F: include/hw/s390x/ap-bridge.h
 F: hw/vfio/ap.c
-F: docs/vfio-ap.txt
+F: docs/system/vfio-ap.rst
 L: qemu-s390x@nongnu.org
 
 vhost

docs/devel/index.rst

@@ -25,3 +25,4 @@ Contents:
    tcg-plugins
    bitops
    reset
+   s390-dasd-ipl

docs/devel/s390-dasd-ipl.rst

@@ -1,25 +1,28 @@
-*****************************
+Booting from real channel-attached devices on s390x
-***** s390 hardware IPL *****
+===================================================
-*****************************
+
+s390 hardware IPL
+-----------------
 
 The s390 hardware IPL process consists of the following steps.
 
-1. A READ IPL ccw is constructed in memory location 0x0.
+1. A READ IPL ccw is constructed in memory location ``0x0``.
    This ccw, by definition, reads the IPL1 record which is located on the disk
    at cylinder 0 track 0 record 1. Note that the chain flag is on in this ccw
    so when it is complete another ccw will be fetched and executed from memory
-    location 0x08.
+   location ``0x08``.
 
-2. Execute the Read IPL ccw at 0x00, thereby reading IPL1 data into 0x00.
+2. Execute the Read IPL ccw at ``0x00``, thereby reading IPL1 data into ``0x00``.
    IPL1 data is 24 bytes in length and consists of the following pieces of
-    information: [psw][read ccw][tic ccw]. When the machine executes the Read
+   information: ``[psw][read ccw][tic ccw]``. When the machine executes the Read
    IPL ccw it read the 24-bytes of IPL1 to be read into memory starting at
-    location 0x0. Then the ccw program at 0x08 which consists of a read
+   location ``0x0``. Then the ccw program at ``0x08`` which consists of a read
    ccw and a tic ccw is automatically executed because of the chain flag from
    the original READ IPL ccw. The read ccw will read the IPL2 data into memory
    and the TIC (Transfer In Channel) will transfer control to the channel
    program contained in the IPL2 data. The TIC channel command is the
    equivalent of a branch/jump/goto instruction for channel programs.
+
    NOTE: The ccws in IPL1 are defined by the architecture to be format 0.
 
 3. Execute IPL2.
@@ -31,15 +34,18 @@ The s390 hardware IPL process consists of the following steps.
    the real operating system is loaded into memory and we are ready to hand
    control over to the guest operating system. At this point the guest
    operating system is entirely responsible for loading any more data it might
-    need to function. NOTE: The IPL2 channel program might read data into memory
+   need to function.
-    location 0 thereby overwriting the IPL1 psw and channel program. This is ok
+
-    as long as the data placed in location 0 contains a psw whose instruction
+   NOTE: The IPL2 channel program might read data into memory
+   location ``0x0`` thereby overwriting the IPL1 psw and channel program. This is ok
+   as long as the data placed in location ``0x0`` contains a psw whose instruction
    address points to the guest operating system code to execute at the end of
    the IPL/boot process.
+
    NOTE: The ccws in IPL2 are defined by the architecture to be format 0.
 
 4. Start executing the guest operating system.
-    The psw that was loaded into memory location 0 as part of the ipl process
+   The psw that was loaded into memory location ``0x0`` as part of the ipl process
    should contain the needed flags for the operating system we have loaded. The
    psw's instruction address will point to the location in memory where we want
    to start executing the operating system. This psw is loaded (via LPSW
@@ -54,18 +60,17 @@ written immediately after the special "Read IPL" ccw, the IPL1 channel program
 will be executed immediately (the special read ccw has the chaining bit turned
 on). The TIC at the end of the IPL1 channel program will cause the IPL2 channel
 program to be executed automatically. After this sequence completes the "Load"
-procedure then loads the psw from 0x0.
+procedure then loads the psw from ``0x0``.
 
-**********************************************************
+How this all pertains to QEMU (and the kernel)
-***** How this all pertains to QEMU (and the kernel) *****
+----------------------------------------------
-**********************************************************
 
 In theory we should merely have to do the following to IPL/boot a guest
 operating system from a DASD device:
 
-1. Place a "Read IPL" ccw into memory location 0x0 with chaining bit on.
+1. Place a "Read IPL" ccw into memory location ``0x0`` with chaining bit on.
-2. Execute channel program at 0x0.
+2. Execute channel program at ``0x0``.
-3. LPSW 0x0.
+3. LPSW ``0x0``.
 
 However, our emulation of the machine's channel program logic within the kernel
 is missing one key feature that is required for this process to work:
@@ -89,32 +94,31 @@ Lastly, in some cases (the zipl bootloader for example) the IPL2 program also
 transfers control to another channel program segment immediately after reading
 it from the disk. So we need to be able to handle this case.
 
-**************************
+What QEMU does
-***** What QEMU does *****
+--------------
-**************************
 
 Since we are forced to live with prefetch we cannot use the very simple IPL
 procedure we defined in the preceding section. So we compensate by doing the
 following.
 
-1. Place "Read IPL" ccw into memory location 0x0, but turn off chaining bit.
+1. Place "Read IPL" ccw into memory location ``0x0``, but turn off chaining bit.
-2. Execute "Read IPL" at 0x0.
+2. Execute "Read IPL" at ``0x0``.
 
-   So now IPL1's psw is at 0x0 and IPL1's channel program is at 0x08.
+   So now IPL1's psw is at ``0x0`` and IPL1's channel program is at ``0x08``.
 
-4. Write a custom channel program that will seek to the IPL2 record and then
+3. Write a custom channel program that will seek to the IPL2 record and then
    execute the READ and TIC ccws from IPL1.  Normally the seek is not required
    because after reading the IPL1 record the disk is automatically positioned
    to read the very next record which will be IPL2. But since we are not reading
    both IPL1 and IPL2 as part of the same channel program we must manually set
    the position.
 
-5. Grab the target address of the TIC instruction from the IPL1 channel program.
+4. Grab the target address of the TIC instruction from the IPL1 channel program.
    This address is where the IPL2 channel program starts.
 
    Now IPL2 is loaded into memory somewhere, and we know the address.
 
-6. Execute the IPL2 channel program at the address obtained in step #5.
+5. Execute the IPL2 channel program at the address obtained in step #4.
 
    Because this channel program can be dynamic, we must use a special algorithm
    that detects a READ immediately followed by a TIC and breaks the ccw chain
@@ -126,8 +130,9 @@ following.
    channel program from executing properly.
 
    Now the operating system code is loaded somewhere in guest memory and the psw
-   in memory location 0x0 will point to entry code for the guest operating
+   in memory location ``0x0`` will point to entry code for the guest operating
    system.
 
-7. LPSW 0x0.
+6. LPSW ``0x0``
+
    LPSW transfers control to the guest operating system and we're done.

docs/system/index.rst

@@ -15,3 +15,4 @@ Contents:
    :maxdepth: 2
 
    qemu-block-drivers
+   vfio-ap

docs/system/vfio-ap.rst

@@ -1,17 +1,11 @@
 Adjunct Processor (AP) Device
 =============================
 
-Contents:
+.. contents::
-=========
+
-* Introduction
+Introduction
-* AP Architectural Overview
+------------
-* Start Interpretive Execution (SIE) Instruction
-* AP Matrix Configuration on Linux Host
-* Starting a Linux Guest Configured with an AP Matrix
-* Example: Configure AP Matrices for Three Linux Guests
 
-Introduction:
-============
 The IBM Adjunct Processor (AP) Cryptographic Facility is comprised
 of three AP instructions and from 1 to 256 PCIe cryptographic adapter cards.
 These AP devices provide cryptographic functions to all CPUs assigned to a
@@ -21,8 +15,9 @@ On s390x, AP adapter cards are exposed via the AP bus. This document
 describes how those cards may be made available to KVM guests using the
 VFIO mediated device framework.
 
-AP Architectural Overview:
+AP Architectural Overview
-=========================
+-------------------------
+
 In order understand the terminology used in the rest of this document, let's
 start with some definitions:
 
@@ -75,7 +70,8 @@ start with some definitions:
   must be one of the control domains.
 
 Start Interpretive Execution (SIE) Instruction
-==============================================
+----------------------------------------------
+
 A KVM guest is started by executing the Start Interpretive Execution (SIE)
 instruction. The SIE state description is a control block that contains the
 state information for a KVM guest and is supplied as input to the SIE
@@ -114,38 +110,60 @@ The APQNs can provide secure key functionality - i.e., a private key is stored
 on the adapter card for each of its domains - so each APQN must be assigned to
 at most one guest or the linux host.
 
-   Example 1: Valid configuration:
+Example 1: Valid configuration
-   ------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-   Guest1: adapters 1,2  domains 5,6
-   Guest2: adapter  1,2  domain 7
 
-   This is valid because both guests have a unique set of APQNs: Guest1 has
++----------+--------+--------+
-   APQNs (1,5), (1,6), (2,5) and (2,6); Guest2 has APQNs (1,7) and (2,7).
+|          | Guest1 | Guest2 |
++==========+========+========+
+| adapters |  1, 2  |  1, 2  |
++----------+--------+--------+
+| domains  |  5, 6  |  7     |
++----------+--------+--------+
 
-   Example 2: Valid configuration:
+This is valid because both guests have a unique set of APQNs:
-   ------------------------------
+
-   Guest1: adapters 1,2 domains 5,6
+* Guest1 has APQNs (1,5), (1,6), (2,5) and (2,6);
-   Guest2: adapters 3,4 domains 5,6
+* Guest2 has APQNs (1,7) and (2,7).
+
+Example 2: Valid configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
++----------+--------+--------+
+|          | Guest1 | Guest2 |
++==========+========+========+
+| adapters |  1, 2  |  3, 4  |
++----------+--------+--------+
+| domains  |  5, 6  |  5, 6  |
++----------+--------+--------+
 
 This is also valid because both guests have a unique set of APQNs:
-      Guest1 has APQNs (1,5), (1,6), (2,5), (2,6);
-      Guest2 has APQNs (3,5), (3,6), (4,5), (4,6)
 
-   Example 3: Invalid configuration:
+* Guest1 has APQNs (1,5), (1,6), (2,5), (2,6);
-   --------------------------------
+* Guest2 has APQNs (3,5), (3,6), (4,5), (4,6)
-   Guest1: adapters 1,2  domains 5,6
+
-   Guest2: adapter  1    domains 6,7
+Example 3: Invalid configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
++----------+--------+--------+
+|          | Guest1 | Guest2 |
++==========+========+========+
+| adapters |  1, 2  |  1     |
++----------+--------+--------+
+| domains  |  5, 6  |  6, 7  |
++----------+--------+--------+
 
 This is an invalid configuration because both guests have access to
 APQN (1,6).
 
-AP Matrix Configuration on Linux Host:
+AP Matrix Configuration on Linux Host
-=====================================
+-------------------------------------
+
 A linux system is a guest of the LPAR in which it is running and has access to
 the AP resources configured for the LPAR. The LPAR's AP matrix is
 configured via its Activation Profile which can be edited on the HMC. When the
 linux system is started, the AP bus will detect the AP devices assigned to the
-LPAR and create the following in sysfs:
+LPAR and create the following in sysfs::
 
   /sys/bus/ap
   ... [devices]
@@ -155,13 +173,16 @@ LPAR and create the following in sysfs:
   ...... ...
 
 Where:
-    cardxx     is AP adapter number xx (in hex)
+
-....xx.yyyy    is an APQN with xx specifying the APID and yyyy specifying the
+``cardxx``
-               APQI
+  is AP adapter number xx (in hex)
+
+``xx.yyyy``
+  is an APQN with xx specifying the APID and yyyy specifying the APQI
 
 For example, if AP adapters 5 and 6 and domains 4, 71 (0x47), 171 (0xab) and
 255 (0xff) are configured for the LPAR, the sysfs representation on the linux
-host system would look like this:
+host system would look like this::
 
   /sys/bus/ap
   ... [devices]
@@ -177,7 +198,7 @@ host system would look like this:
   ...... card06
 
 A set of default device drivers are also created to control each type of AP
-device that can be assigned to the LPAR on which a linux host is running:
+device that can be assigned to the LPAR on which a linux host is running::
 
   /sys/bus/ap
   ... [drivers]
@@ -193,30 +214,31 @@ device that can be assigned to the LPAR on which a linux host is running:
                             coprocessor cards
 
 Binding AP devices to device drivers
-------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 There are two sysfs files that specify bitmasks marking a subset of the APQN
 range as 'usable by the default AP queue device drivers' or 'not usable by the
 default device drivers' and thus available for use by the alternate device
-driver(s). The sysfs locations of the masks are:
+driver(s). The sysfs locations of the masks are::
 
    /sys/bus/ap/apmask
    /sys/bus/ap/aqmask
 
-   The 'apmask' is a 256-bit mask that identifies a set of AP adapter IDs
+The ``apmask`` is a 256-bit mask that identifies a set of AP adapter IDs
 (APID). Each bit in the mask, from left to right (i.e., from most significant
 to least significant bit in big endian order), corresponds to an APID from
 0-255. If a bit is set, the APID is marked as usable only by the default AP
 queue device drivers; otherwise, the APID is usable by the vfio_ap
 device driver.
 
-   The 'aqmask' is a 256-bit mask that identifies a set of AP queue indexes
+The ``aqmask`` is a 256-bit mask that identifies a set of AP queue indexes
 (APQI). Each bit in the mask, from left to right (i.e., from most significant
 to least significant bit in big endian order), corresponds to an APQI from
 0-255. If a bit is set, the APQI is marked as usable only by the default AP
 queue device drivers; otherwise, the APQI is usable by the vfio_ap device
 driver.
 
-   Take, for example, the following mask:
+Take, for example, the following mask::
 
       0x7dffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
 
@@ -240,29 +262,30 @@ driver(s). The sysfs locations of the masks are:
     * An absolute hex string starting with 0x - like "0x12345678" - sets
       the mask. If the given string is shorter than the mask, it is padded
       with 0s on the right; for example, specifying a mask value of 0x41 is
-        the same as specifying:
+      the same as specifying::
 
            0x4100000000000000000000000000000000000000000000000000000000000000
 
       Keep in mind that the mask reads from left to right (i.e., most
       significant to least significant bit in big endian order), so the mask
-        above identifies device numbers 1 and 7 (01000001).
+      above identifies device numbers 1 and 7 (``01000001``).
 
       If the string is longer than the mask, the operation is terminated with
       an error (EINVAL).
 
     * Individual bits in the mask can be switched on and off by specifying
       each bit number to be switched in a comma separated list. Each bit
-        number string must be prepended with a ('+') or minus ('-') to indicate
+      number string must be prepended with a (``+``) or minus (``-``) to indicate
-        the corresponding bit is to be switched on ('+') or off ('-'). Some
+      the corresponding bit is to be switched on (``+``) or off (``-``). Some
-        valid values are:
+      valid values are::
 
            "+0"    switches bit 0 on
            "-13"   switches bit 13 off
            "+0x41" switches bit 65 on
            "-0xff" switches bit 255 off
 
-           The following example:
+      The following example::
+
               +0,-6,+0x47,-0xf0
 
       Switches bits 0 and 71 (0x47) on
@@ -272,31 +295,34 @@ driver(s). The sysfs locations of the masks are:
       the operation.
 
  2. The masks can also be changed at boot time via parameters on the kernel
-      command line like this:
+    command line like this::
 
          ap.apmask=0xffff ap.aqmask=0x40
 
     This would create the following masks:
 
-            apmask:
+    apmask::
+
             0xffff000000000000000000000000000000000000000000000000000000000000
 
-            aqmask:
+    aqmask::
+
             0x4000000000000000000000000000000000000000000000000000000000000000
 
-         Resulting in these two pools:
+    Resulting in these two pools::
 
             default drivers pool:    adapter 0-15, domain 1
             alternate drivers pool:  adapter 16-255, domains 0, 2-255
 
-Configuring an AP matrix for a linux guest.
+Configuring an AP matrix for a linux guest
-------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 The sysfs interfaces for configuring an AP matrix for a guest are built on the
 VFIO mediated device framework. To configure an AP matrix for a guest, a
-mediated matrix device must first be created for the /sys/devices/vfio_ap/matrix
+mediated matrix device must first be created for the ``/sys/devices/vfio_ap/matrix``
 device. When the vfio_ap device driver is loaded, it registers with the VFIO
 mediated device framework. When the driver registers, the sysfs interfaces for
-creating mediated matrix devices is created:
+creating mediated matrix devices is created::
 
   /sys/devices
   ... [vfio_ap]
@@ -307,16 +333,18 @@ creating mediated matrix devices is created:
   ............... [devices]
 
 A mediated AP matrix device is created by writing a UUID to the attribute file
-named 'create', for example:
+named ``create``, for example::
 
    uuidgen > create
 
 or
 
+::
+
    echo $uuid > create
 
 When a mediated AP matrix device is created, a sysfs directory named after
-the UUID is created in the 'devices' subdirectory:
+the UUID is created in the ``devices`` subdirectory::
 
   /sys/devices
   ... [vfio_ap]
@@ -329,7 +357,7 @@ the UUID is created in the 'devices' subdirectory:
 
 There will also be three sets of attribute files created in the mediated
 matrix device's sysfs directory to configure an AP matrix for the
-KVM guest:
+KVM guest::
 
   /sys/devices
   ... [vfio_ap]
@@ -347,13 +375,13 @@ KVM guest:
   ..................... unassign_control_domain
   ..................... unassign_domain
 
-assign_adapter
+``assign_adapter``
    To assign an AP adapter to the mediated matrix device, its APID is written
-   to the 'assign_adapter' file. This may be done multiple times to assign more
+   to the ``assign_adapter`` file. This may be done multiple times to assign more
    than one adapter. The APID may be specified using conventional semantics
    as a decimal, hexadecimal, or octal number. For example, to assign adapters
    4, 5 and 16 to a mediated matrix device in decimal, hexadecimal and octal
-   respectively:
+   respectively::
 
        echo 4 > assign_adapter
        echo 0x5 > assign_adapter
@@ -373,22 +401,22 @@ assign_adapter
      APQNs are bound to the driver, the operation will terminate with an
      error (EADDRNOTAVAIL).
 
-     No APQN that can be derived from the adapter ID and the IDs of the
+   * No APQN that can be derived from the adapter ID and the IDs of the
      previously assigned domains can be assigned to another mediated matrix
      device. If an APQN is assigned to another mediated matrix device, the
      operation will terminate with an error (EADDRINUSE).
 
-unassign_adapter
+``unassign_adapter``
-   To unassign an AP adapter, its APID is written to the 'unassign_adapter'
+   To unassign an AP adapter, its APID is written to the ``unassign_adapter``
    file. This may also be done multiple times to unassign more than one adapter.
 
-assign_domain
+``assign_domain``
    To assign a usage domain, the domain number is written into the
-   'assign_domain' file. This may be done multiple times to assign more than one
+   ``assign_domain`` file. This may be done multiple times to assign more than one
    usage domain. The domain number is specified using conventional semantics as
    a decimal, hexadecimal, or octal number. For example, to assign usage domains
    4, 8, and 71 to a mediated matrix device in decimal, hexadecimal and octal
-   respectively:
+   respectively::
 
       echo 4 > assign_domain
       echo 0x8 > assign_domain
@@ -408,23 +436,23 @@ assign_domain
      APQNs are bound to the driver, the operation will terminate with an
      error (EADDRNOTAVAIL).
 
-     No APQN that can be derived from the domain ID being assigned and the IDs
+   * No APQN that can be derived from the domain ID being assigned and the IDs
      of the previously assigned adapters can be assigned to another mediated
      matrix device. If an APQN is assigned to another mediated matrix device,
      the operation will terminate with an error (EADDRINUSE).
 
-unassign_domain
+``unassign_domain``
    To unassign a usage domain, the domain number is written into the
-   'unassign_domain' file. This may be done multiple times to unassign more than
+   ``unassign_domain`` file. This may be done multiple times to unassign more than
    one usage domain.
 
-assign_control_domain
+``assign_control_domain``
    To assign a control domain, the domain number is written into the
-   'assign_control_domain' file. This may be done multiple times to
+   ``assign_control_domain`` file. This may be done multiple times to
    assign more than one control domain. The domain number may be specified using
    conventional semantics as a decimal, hexadecimal, or octal number. For
    example, to assign  control domains 4, 8, and 71 to  a mediated matrix device
-   in decimal, hexadecimal and octal respectively:
+   in decimal, hexadecimal and octal respectively::
 
       echo 4 > assign_domain
       echo 0x8 > assign_domain
@@ -435,24 +463,25 @@ assign_control_domain
    allowed by the machine model. If a control domain number higher than the
    maximum is specified, the operation will terminate with an error (ENODEV).
 
-unassign_control_domain
+``unassign_control_domain``
    To unassign a control domain, the domain number is written into the
-   'unassign_domain' file. This may be done multiple times to unassign more than
+   ``unassign_domain`` file. This may be done multiple times to unassign more than
    one control domain.
 
 Notes: No changes to the AP matrix will be allowed while a guest using
 the mediated matrix device is running. Attempts to assign an adapter,
 domain or control domain will be rejected and an error (EBUSY) returned.
 
-Starting a Linux Guest Configured with an AP Matrix:
+Starting a Linux Guest Configured with an AP Matrix
-===================================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 To provide a mediated matrix device for use by a guest, the following option
-must be specified on the QEMU command line:
+must be specified on the QEMU command line::
 
    -device vfio_ap,sysfsdev=$path-to-mdev
 
 The sysfsdev parameter specifies the path to the mediated matrix device.
-There are a number of ways to specify this path:
+There are a number of ways to specify this path::
 
   /sys/devices/vfio_ap/matrix/$uuid
   /sys/bus/mdev/devices/$uuid
@@ -461,7 +490,7 @@ There are a number of ways to specify this path:
 
 When the linux guest is started, the guest will open the mediated
 matrix device's file descriptor to get information about the mediated matrix
-device. The vfio_ap device driver will update the APM, AQM, and ADM fields in
+device. The ``vfio_ap`` device driver will update the APM, AQM, and ADM fields in
 the guest's CRYCB with the adapter, usage domain and control domains assigned
 via the mediated matrix device's sysfs attribute files. Programs running on the
 linux guest will then:
@@ -486,19 +515,21 @@ facilities:
    The AP facilities feature indicates that AP facilities are installed on the
    guest. This feature will be exposed for use only if the AP facilities
    are installed on the host system. The feature is s390-specific and is
-   represented as a parameter of the -cpu option on the QEMU command line:
+   represented as a parameter of the -cpu option on the QEMU command line::
 
       qemu-system-s390x -cpu $model,ap=on|off
 
    Where:
 
-         $model is the CPU model defined for the guest (defaults to the model of
+      ``$model``
+        is the CPU model defined for the guest (defaults to the model of
         the host system if not specified).
 
-         ap=on|off indicates whether AP facilities are installed (on) or not
+      ``ap=on|off``
+        indicates whether AP facilities are installed (on) or not
         (off). The default for CPU models zEC12 or newer
-                   is ap=on. AP facilities must be installed on the guest if a
+        is ``ap=on``. AP facilities must be installed on the guest if a
-                   vfio-ap device (-device vfio-ap,sysfsdev=$path) is configured
+        vfio-ap device (``-device vfio-ap,sysfsdev=$path``) is configured
         for the guest, or the guest will fail to start.
 
 2. Query Configuration Information (QCI) facility
@@ -507,20 +538,22 @@ facilities:
    configuration of the AP facilities. This facility will be available
    only if the QCI facility is installed on the host system. The feature is
    s390-specific and is represented as a parameter of the -cpu option on the
-   QEMU command line:
+   QEMU command line::
 
       qemu-system-s390x -cpu $model,apqci=on|off
 
    Where:
 
-         $model is the CPU model defined for the guest
+      ``$model``
+        is the CPU model defined for the guest
 
-         apqci=on|off indicates whether the QCI facility is installed (on) or
+      ``apqci=on|off``
+        indicates whether the QCI facility is installed (on) or
         not (off). The default for CPU models zEC12 or newer
-                      is apqci=on; for older models, QCI will not be installed.
+        is ``apqci=on``; for older models, QCI will not be installed.
 
-                      If QCI is installed (apqci=on) but AP facilities are not
+        If QCI is installed (``apqci=on``) but AP facilities are not
-                      (ap=off), an error message will be logged, but the guest
+        (``ap=off``), an error message will be logged, but the guest
         will be allowed to start. It makes no sense to have QCI
         installed if the AP facilities are not; this is considered
         an invalid configuration.
@@ -535,22 +568,24 @@ facilities:
    AP facilities available for a given AP queue. This facility will be available
    only if the APFT facility is installed on the host system. The feature is
    s390-specific and is represented as a parameter of the -cpu option on the
-   QEMU command line:
+   QEMU command line::
 
       qemu-system-s390x -cpu $model,apft=on|off
 
    Where:
 
-         $model is the CPU model defined for the guest (defaults to the model of
+      ``$model``
+        is the CPU model defined for the guest (defaults to the model of
         the host system if not specified).
 
-         apft=on|off indicates whether the APFT facility is installed (on) or
+      ``apft=on|off``
+        indicates whether the APFT facility is installed (on) or
         not (off). The default for CPU models zEC12 and
-                     newer is apft=on for older models, APFT will not be
+        newer is ``apft=on`` for older models, APFT will not be
         installed.
 
-                     If APFT is installed (apft=on) but AP facilities are not
+        If APFT is installed (``apft=on``) but AP facilities are not
-                     (ap=off), an error message will be logged, but the guest
+        (``ap=off``), an error message will be logged, but the guest
         will be allowed to start. It makes no sense to have APFT
         installed if the AP facilities are not; this is considered
         an invalid configuration.
@@ -561,22 +596,23 @@ facilities:
         for guest usage, no AP devices can be made accessible to a
         guest started without APFT installed.
 
-Hot plug a vfio-ap device into a running guest:
+Hot plug a vfio-ap device into a running guest
-==============================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 Only one vfio-ap device can be attached to the virtual machine's ap-bus, so a
 vfio-ap device can be hot plugged if and only if no vfio-ap device is attached
 to the bus already, whether via the QEMU command line or a prior hot plug
 action.
 
-To hot plug a vfio-ap device, use the QEMU device_add command:
+To hot plug a vfio-ap device, use the QEMU ``device_add`` command::
 
     (qemu) device_add vfio-ap,sysfsdev="$path-to-mdev"
 
-    Where the '$path-to-mdev' value specifies the absolute path to a mediated
+Where the ``$path-to-mdev`` value specifies the absolute path to a mediated
 device to which AP resources to be used by the guest have been assigned.
 
 Note that on Linux guests, the AP devices will be created in the
-/sys/bus/ap/devices directory when the AP bus subsequently performs its periodic
+``/sys/bus/ap/devices`` directory when the AP bus subsequently performs its periodic
 scan, so there may be a short delay before the AP devices are accessible on the
 guest.
 
@@ -587,37 +623,39 @@ The command will fail if:
 * The CPU model features for controlling guest access to AP facilities are not
   enabled (see 'CPU model features' subsection in the previous section).
 
-Hot unplug a vfio-ap device from a running guest:
+Hot unplug a vfio-ap device from a running guest
-================================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 A vfio-ap device can be unplugged from a running KVM guest if a vfio-ap device
 has been attached to the virtual machine's ap-bus via the QEMU command line
 or a prior hot plug action.
 
-To hot unplug a vfio-ap device, use the QEMU device_del command:
+To hot unplug a vfio-ap device, use the QEMU ``device_del`` command::
 
     (qemu) device_del vfio-ap,sysfsdev="$path-to-mdev"
 
-    Where $path-to-mdev is the same as the path specified when the vfio-ap
+Where ``$path-to-mdev`` is the same as the path specified when the vfio-ap
 device was attached to the virtual machine's ap-bus.
 
-On a Linux guest, the AP devices will be removed from the /sys/bus/ap/devices
+On a Linux guest, the AP devices will be removed from the ``/sys/bus/ap/devices``
 directory on the guest when the AP bus subsequently performs its periodic scan,
 so there may be a short delay before the AP devices are no longer accessible by
 the guest.
 
-The command will fail if the $path-to-mdev specified on the device_del command
+The command will fail if the ``$path-to-mdev`` specified on the ``device_del`` command
 does not match the value specified when the vfio-ap device was attached to
 the virtual machine's ap-bus.
 
-Example: Configure AP Matrixes for Three Linux Guests:
+Example: Configure AP Matrices for Three Linux Guests
-=====================================================
+-----------------------------------------------------
+
 Let's now provide an example to illustrate how KVM guests may be given
 access to AP facilities. For this example, we will show how to configure
 three guests such that executing the lszcrypt command on the guests would
 look like this:
 
-Guest1
+Guest1::
-------
+
   CARD.DOMAIN TYPE  MODE
   ------------------------------
   05          CEX5C CCA-Coproc
@@ -627,16 +665,16 @@ CARD.DOMAIN TYPE  MODE
   06.0004     CEX5A Accelerator
   06.00ab     CEX5C CCA-Coproc
 
-Guest2
+Guest2::
-------
+
   CARD.DOMAIN TYPE  MODE
   ------------------------------
   05          CEX5A Accelerator
   05.0047     CEX5A Accelerator
-05.00ff     CEX5A Accelerator (5,4), (5,171), (6,4), (6,171),
+  05.00ff     CEX5A Accelerator
+
+Guest3::
 
-Guest3
-------
   CARD.DOMAIN TYPE  MODE
   ------------------------------
   06          CEX5A Accelerator
@@ -647,6 +685,7 @@ These are the steps:
 
 1. Install the vfio_ap module on the linux host. The dependency chain for the
    vfio_ap module is:
+
    * iommu
    * s390
    * zcrypt
@@ -657,6 +696,7 @@ These are the steps:
 
    To build the vfio_ap module, the kernel build must be configured with the
    following Kconfig elements selected:
+
    * IOMMU_SUPPORT
    * S390
    * ZCRYPT
@@ -666,7 +706,7 @@ These are the steps:
    * VFIO_MDEV_DEVICE
    * KVM
 
-   If using make menuconfig select the following to build the vfio_ap module:
+   If using make menuconfig select the following to build the vfio_ap module::
      -> Device Drivers
         -> IOMMU Hardware Support
            select S390 AP IOMMU Support
@@ -680,7 +720,7 @@ These are the steps:
    access them. To secure the AP queues 05.0004, 05.0047, 05.00ab, 05.00ff,
    06.0004, 06.0047, 06.00ab, and 06.00ff for use by the vfio_ap device driver,
    the corresponding APQNs must be removed from the default queue drivers pool
-   as follows:
+   as follows::
 
       echo -5,-6 > /sys/bus/ap/apmask
 
@@ -689,7 +729,7 @@ These are the steps:
    This will result in AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004,
    06.0047, 06.00ab, and 06.00ff getting bound to the vfio_ap device driver. The
    sysfs directory for the vfio_ap device driver will now contain symbolic links
-   to the AP queue devices bound to it:
+   to the AP queue devices bound to it::
 
      /sys/bus/ap
      ... [drivers]
@@ -712,7 +752,7 @@ These are the steps:
    The administrator, therefore, must take care to secure only AP queues that
    can be bound to the vfio_ap device driver. The device type for a given AP
    queue device can be read from the parent card's sysfs directory. For example,
-   to see the hardware type of the queue 05.0004:
+   to see the hardware type of the queue 05.0004::
 
      cat /sys/bus/ap/devices/card05/hwtype
 
@@ -721,15 +761,15 @@ These are the steps:
 
 3. Create the mediated devices needed to configure the AP matrixes for the
    three guests and to provide an interface to the vfio_ap driver for
-   use by the guests:
+   use by the guests::
 
      /sys/devices/vfio_ap/matrix/
-   --- [mdev_supported_types]
+     ... [mdev_supported_types]
-   ------ [vfio_ap-passthrough] (passthrough mediated matrix device type)
+     ...... [vfio_ap-passthrough] (passthrough mediated matrix device type)
-   --------- create
+     ......... create
-   --------- [devices]
+     ......... [devices]
 
-   To create the mediated devices for the three guests:
+   To create the mediated devices for the three guests::
 
        uuidgen > create
        uuidgen > create
@@ -737,49 +777,51 @@ These are the steps:
 
    or
 
+   ::
+
        echo $uuid1 > create
        echo $uuid2 > create
        echo $uuid3 > create
 
    This will create three mediated devices in the [devices] subdirectory named
    after the UUID used to create the mediated device. We'll call them $uuid1,
-   $uuid2 and $uuid3 and this is the sysfs directory structure after creation:
+   $uuid2 and $uuid3 and this is the sysfs directory structure after creation::
 
      /sys/devices/vfio_ap/matrix/
-   --- [mdev_supported_types]
+     ... [mdev_supported_types]
-   ------ [vfio_ap-passthrough]
+     ...... [vfio_ap-passthrough]
-   --------- [devices]
+     ......... [devices]
-   ------------ [$uuid1]
+     ............ [$uuid1]
-   --------------- assign_adapter
+     ............... assign_adapter
-   --------------- assign_control_domain
+     ............... assign_control_domain
-   --------------- assign_domain
+     ............... assign_domain
-   --------------- matrix
+     ............... matrix
-   --------------- unassign_adapter
+     ............... unassign_adapter
-   --------------- unassign_control_domain
+     ............... unassign_control_domain
-   --------------- unassign_domain
+     ............... unassign_domain
 
-   ------------ [$uuid2]
+     ............ [$uuid2]
-   --------------- assign_adapter
+     ............... assign_adapter
-   --------------- assign_control_domain
+     ............... assign_control_domain
-   --------------- assign_domain
+     ............... assign_domain
-   --------------- matrix
+     ............... matrix
-   --------------- unassign_adapter
+     ............... unassign_adapter
-   ----------------unassign_control_domain
+     ............... unassign_control_domain
-   ----------------unassign_domain
+     ............... unassign_domain
 
-   ------------ [$uuid3]
+     ............ [$uuid3]
-   --------------- assign_adapter
+     ............... assign_adapter
-   --------------- assign_control_domain
+     ............... assign_control_domain
-   --------------- assign_domain
+     ............... assign_domain
-   --------------- matrix
+     ............... matrix
-   --------------- unassign_adapter
+     ............... unassign_adapter
-   ----------------unassign_control_domain
+     ............... unassign_control_domain
-   ----------------unassign_domain
+     ............... unassign_domain
 
 4. The administrator now needs to configure the matrixes for the mediated
    devices $uuid1 (for Guest1), $uuid2 (for Guest2) and $uuid3 (for Guest3).
 
-   This is how the matrix is configured for Guest1:
+   This is how the matrix is configured for Guest1::
 
       echo 5 > assign_adapter
       echo 6 > assign_adapter
@@ -790,59 +832,56 @@ These are the steps:
    sysfs file.
 
    If a mistake is made configuring an adapter, domain or control domain,
-      you can use the unassign_xxx interfaces to unassign the adapter, domain or
+   you can use the ``unassign_xxx`` interfaces to unassign the adapter, domain or
    control domain.
 
-      To display the matrix configuration for Guest1:
+   To display the matrix configuration for Guest1::
 
          cat matrix
 
-         The output will display the APQNs in the format xx.yyyy, where xx is
+   The output will display the APQNs in the format ``xx.yyyy``, where xx is
    the adapter number and yyyy is the domain number. The output for Guest1
-         will look like this:
+   will look like this::
 
          05.0004
          05.00ab
          06.0004
          06.00ab
 
-   This is how the matrix is configured for Guest2:
+   This is how the matrix is configured for Guest2::
 
       echo 5 > assign_adapter
       echo 0x47 > assign_domain
       echo 0xff > assign_domain
 
-   This is how the matrix is configured for Guest3:
+   This is how the matrix is configured for Guest3::
 
       echo 6 > assign_adapter
       echo 0x47 > assign_domain
       echo 0xff > assign_domain
 
-5. Start Guest1:
+5. Start Guest1::
 
-   /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \
+   /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ...
-      -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ...
 
-7. Start Guest2:
+7. Start Guest2::
 
-   /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \
+   /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ...
-      -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ...
 
-7. Start Guest3:
+7. Start Guest3::
 
-   /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on \
+   /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ...
-      -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ...
 
 When the guest is shut down, the mediated matrix devices may be removed.
 
-Using our example again, to remove the mediated matrix device $uuid1:
+Using our example again, to remove the mediated matrix device $uuid1::
 
    /sys/devices/vfio_ap/matrix/
-      --- [mdev_supported_types]
+   ... [mdev_supported_types]
-      ------ [vfio_ap-passthrough]
+   ...... [vfio_ap-passthrough]
-      --------- [devices]
+   ......... [devices]
-      ------------ [$uuid1]
+   ............ [$uuid1]
-      --------------- remove
+   ............... remove
 
 
    echo 1 > remove
@@ -858,7 +897,8 @@ Using our example again, to remove the mediated matrix device $uuid1:
 the pool of adapters and queues reserved for use by the default drivers.
 
 Limitations
-===========
+-----------
+
 * The KVM/kernel interfaces do not provide a way to prevent restoring an APQN
   to the default drivers pool of a queue that is still assigned to a mediated
   device in use by a guest. It is incumbent upon the administrator to
@@ -867,10 +907,10 @@ Limitations
   device, such as a private key configured specifically for the guest.
 
 * Dynamically assigning AP resources to or unassigning AP resources from a
-  mediated matrix device - see 'Configuring an AP matrix for a linux guest'
+  mediated matrix device - see `Configuring an AP matrix for a linux guest`_
   section above - while a running guest is using it is currently not supported.
 
 * Live guest migration is not supported for guests using AP devices. If a guest
   is using AP devices, the vfio-ap device configured for the guest must be
-  unplugged before migrating the guest (see 'Hot unplug a vfio-ap device from a
+  unplugged before migrating the guest (see `Hot unplug a vfio-ap device from a
-  running guest' section above.
+  running guest`_ section above.)

hw/s390x/ipl.c

@@ -179,7 +179,7 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
                 /* if not Linux load the address of the (short) IPL PSW */
                 ipl_psw = rom_ptr(4, 4);
                 if (ipl_psw) {
-                    pentry = be32_to_cpu(*ipl_psw) & 0x7fffffffUL;
+                    pentry = be32_to_cpu(*ipl_psw) & PSW_MASK_SHORT_ADDR;
                 } else {
                     error_setg(&err, "Could not get IPL PSW");
                     goto error;

include/standard-headers/drm/drm_fourcc.h

@@ -409,6 +409,30 @@ extern "C" {
 #define I915_FORMAT_MOD_Y_TILED_CCS	fourcc_mod_code(INTEL, 4)
 #define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)
 
+/*
+ * Intel color control surfaces (CCS) for Gen-12 render compression.
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
+
+/*
+ * Intel color control surfaces (CCS) for Gen-12 media compression
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
+ * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
+ * planes 2 and 3 for the respective CCS.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
+
 /*
  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
  *

include/standard-headers/linux/ethtool.h

@@ -593,6 +593,9 @@ struct ethtool_pauseparam {
  * @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
  * @ETH_SS_PHY_STATS: Statistic names, for use with %ETHTOOL_GPHYSTATS
  * @ETH_SS_PHY_TUNABLES: PHY tunable names
+ * @ETH_SS_LINK_MODES: link mode names
+ * @ETH_SS_MSG_CLASSES: debug message class names
+ * @ETH_SS_WOL_MODES: wake-on-lan modes
  */
 enum ethtool_stringset {
 	ETH_SS_TEST		= 0,
@@ -604,6 +607,12 @@ enum ethtool_stringset {
 	ETH_SS_TUNABLES,
 	ETH_SS_PHY_STATS,
 	ETH_SS_PHY_TUNABLES,
+	ETH_SS_LINK_MODES,
+	ETH_SS_MSG_CLASSES,
+	ETH_SS_WOL_MODES,
+
+	/* add new constants above here */
+	ETH_SS_COUNT
 };
 
 /**
@@ -1688,6 +1697,8 @@ static inline int ethtool_validate_duplex(uint8_t duplex)
 #define WAKE_MAGICSECURE	(1 << 6) /* only meaningful if WAKE_MAGIC */
 #define WAKE_FILTER		(1 << 7)
 
+#define WOL_MODE_COUNT		8
+
 /* L2-L4 network traffic flow types */
 #define	TCP_V4_FLOW	0x01	/* hash or spec (tcp_ip4_spec) */
 #define	UDP_V4_FLOW	0x02	/* hash or spec (udp_ip4_spec) */

include/standard-headers/linux/input.h

@@ -31,6 +31,7 @@ struct input_event {
 	unsigned long __sec;
 #if defined(__sparc__) && defined(__arch64__)
 	unsigned int __usec;
+	unsigned int __pad;
 #else
 	unsigned long __usec;
 #endif

include/standard-headers/linux/pci_regs.h

@@ -676,6 +676,7 @@
 #define  PCI_EXP_LNKCTL2_TLS_32_0GT	0x0005 /* Supported Speed 32GT/s */
 #define  PCI_EXP_LNKCTL2_ENTER_COMP	0x0010 /* Enter Compliance */
 #define  PCI_EXP_LNKCTL2_TX_MARGIN	0x0380 /* Transmit Margin */
+#define  PCI_EXP_LNKCTL2_HASD		0x0020 /* HW Autonomous Speed Disable */
 #define PCI_EXP_LNKSTA2		50	/* Link Status 2 */
 #define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2	52	/* v2 endpoints with link end here */
 #define PCI_EXP_SLTCAP2		52	/* Slot Capabilities 2 */

linux-headers/asm-arm/unistd-common.h

@@ -390,5 +390,7 @@
 #define __NR_fspick (__NR_SYSCALL_BASE + 433)
 #define __NR_pidfd_open (__NR_SYSCALL_BASE + 434)
 #define __NR_clone3 (__NR_SYSCALL_BASE + 435)
+#define __NR_openat2 (__NR_SYSCALL_BASE + 437)
+#define __NR_pidfd_getfd (__NR_SYSCALL_BASE + 438)
 
 #endif /* _ASM_ARM_UNISTD_COMMON_H */

linux-headers/asm-arm64/kvm.h

@@ -220,10 +220,18 @@ struct kvm_vcpu_events {
 #define KVM_REG_ARM_PTIMER_CVAL		ARM64_SYS_REG(3, 3, 14, 2, 2)
 #define KVM_REG_ARM_PTIMER_CNT		ARM64_SYS_REG(3, 3, 14, 0, 1)
 
-/* EL0 Virtual Timer Registers */
+/*
+ * EL0 Virtual Timer Registers
+ *
+ * WARNING:
+ *      KVM_REG_ARM_TIMER_CVAL and KVM_REG_ARM_TIMER_CNT are not defined
+ *      with the appropriate register encodings.  Their values have been
+ *      accidentally swapped.  As this is set API, the definitions here
+ *      must be used, rather than ones derived from the encodings.
+ */
 #define KVM_REG_ARM_TIMER_CTL		ARM64_SYS_REG(3, 3, 14, 3, 1)
-#define KVM_REG_ARM_TIMER_CNT		ARM64_SYS_REG(3, 3, 14, 3, 2)
 #define KVM_REG_ARM_TIMER_CVAL		ARM64_SYS_REG(3, 3, 14, 0, 2)
+#define KVM_REG_ARM_TIMER_CNT		ARM64_SYS_REG(3, 3, 14, 3, 2)
 
 /* KVM-as-firmware specific pseudo-registers */
 #define KVM_REG_ARM_FW			(0x0014 << KVM_REG_ARM_COPROC_SHIFT)

linux-headers/asm-arm64/unistd.h

@@ -19,5 +19,6 @@
 #define __ARCH_WANT_NEW_STAT
 #define __ARCH_WANT_SET_GET_RLIMIT
 #define __ARCH_WANT_TIME32_SYSCALLS
+#define __ARCH_WANT_SYS_CLONE3
 
 #include <asm-generic/unistd.h>

linux-headers/asm-generic/mman-common.h

@@ -11,6 +11,8 @@
 #define PROT_WRITE	0x2		/* page can be written */
 #define PROT_EXEC	0x4		/* page can be executed */
 #define PROT_SEM	0x8		/* page may be used for atomic ops */
+/*			0x10		   reserved for arch-specific use */
+/*			0x20		   reserved for arch-specific use */
 #define PROT_NONE	0x0		/* page can not be accessed */
 #define PROT_GROWSDOWN	0x01000000	/* mprotect flag: extend change to start of growsdown vma */
 #define PROT_GROWSUP	0x02000000	/* mprotect flag: extend change to end of growsup vma */

linux-headers/asm-generic/unistd.h

@@ -851,8 +851,13 @@ __SYSCALL(__NR_pidfd_open, sys_pidfd_open)
 __SYSCALL(__NR_clone3, sys_clone3)
 #endif
 
+#define __NR_openat2 437
+__SYSCALL(__NR_openat2, sys_openat2)
+#define __NR_pidfd_getfd 438
+__SYSCALL(__NR_pidfd_getfd, sys_pidfd_getfd)
+
 #undef __NR_syscalls
-#define __NR_syscalls 436
+#define __NR_syscalls 439
 
 /*
  * 32 bit systems traditionally used different

linux-headers/asm-mips/unistd_n32.h

@@ -365,6 +365,8 @@
 #define __NR_fspick	(__NR_Linux + 433)
 #define __NR_pidfd_open	(__NR_Linux + 434)
 #define __NR_clone3	(__NR_Linux + 435)
+#define __NR_openat2	(__NR_Linux + 437)
+#define __NR_pidfd_getfd	(__NR_Linux + 438)
 
 
 #endif /* _ASM_MIPS_UNISTD_N32_H */

linux-headers/asm-mips/unistd_n64.h

@@ -341,6 +341,8 @@
 #define __NR_fspick	(__NR_Linux + 433)
 #define __NR_pidfd_open	(__NR_Linux + 434)
 #define __NR_clone3	(__NR_Linux + 435)
+#define __NR_openat2	(__NR_Linux + 437)
+#define __NR_pidfd_getfd	(__NR_Linux + 438)
 
 
 #endif /* _ASM_MIPS_UNISTD_N64_H */

linux-headers/asm-mips/unistd_o32.h

@@ -411,6 +411,8 @@
 #define __NR_fspick	(__NR_Linux + 433)
 #define __NR_pidfd_open	(__NR_Linux + 434)
 #define __NR_clone3	(__NR_Linux + 435)
+#define __NR_openat2	(__NR_Linux + 437)
+#define __NR_pidfd_getfd	(__NR_Linux + 438)
 
 
 #endif /* _ASM_MIPS_UNISTD_O32_H */

linux-headers/asm-powerpc/unistd_32.h

@@ -418,6 +418,8 @@
 #define __NR_fspick	433
 #define __NR_pidfd_open	434
 #define __NR_clone3	435
+#define __NR_openat2	437
+#define __NR_pidfd_getfd	438
 
 
 #endif /* _ASM_POWERPC_UNISTD_32_H */

linux-headers/asm-powerpc/unistd_64.h

@@ -390,6 +390,8 @@
 #define __NR_fspick	433
 #define __NR_pidfd_open	434
 #define __NR_clone3	435
+#define __NR_openat2	437
+#define __NR_pidfd_getfd	438
 
 
 #endif /* _ASM_POWERPC_UNISTD_64_H */

linux-headers/asm-s390/unistd_32.h

@@ -408,5 +408,7 @@
 #define __NR_fspick 433
 #define __NR_pidfd_open 434
 #define __NR_clone3 435
+#define __NR_openat2 437
+#define __NR_pidfd_getfd 438
 
 #endif /* _ASM_S390_UNISTD_32_H */

linux-headers/asm-s390/unistd_64.h

@@ -356,5 +356,7 @@
 #define __NR_fspick 433
 #define __NR_pidfd_open 434
 #define __NR_clone3 435
+#define __NR_openat2 437
+#define __NR_pidfd_getfd 438
 
 #endif /* _ASM_S390_UNISTD_64_H */

linux-headers/asm-x86/unistd_32.h

@@ -426,5 +426,7 @@
 #define __NR_fspick 433
 #define __NR_pidfd_open 434
 #define __NR_clone3 435
+#define __NR_openat2 437
+#define __NR_pidfd_getfd 438
 
 #endif /* _ASM_X86_UNISTD_32_H */

linux-headers/asm-x86/unistd_64.h

@@ -348,5 +348,7 @@
 #define __NR_fspick 433
 #define __NR_pidfd_open 434
 #define __NR_clone3 435
+#define __NR_openat2 437
+#define __NR_pidfd_getfd 438
 
 #endif /* _ASM_X86_UNISTD_64_H */

linux-headers/asm-x86/unistd_x32.h

@@ -301,6 +301,8 @@
 #define __NR_fspick (__X32_SYSCALL_BIT + 433)
 #define __NR_pidfd_open (__X32_SYSCALL_BIT + 434)
 #define __NR_clone3 (__X32_SYSCALL_BIT + 435)
+#define __NR_openat2 (__X32_SYSCALL_BIT + 437)
+#define __NR_pidfd_getfd (__X32_SYSCALL_BIT + 438)
 #define __NR_rt_sigaction (__X32_SYSCALL_BIT + 512)
 #define __NR_rt_sigreturn (__X32_SYSCALL_BIT + 513)
 #define __NR_ioctl (__X32_SYSCALL_BIT + 514)

linux-headers/linux/kvm.h

@@ -1009,6 +1009,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_PPC_GUEST_DEBUG_SSTEP 176
 #define KVM_CAP_ARM_NISV_TO_USER 177
 #define KVM_CAP_ARM_INJECT_EXT_DABT 178
+#define KVM_CAP_S390_VCPU_RESETS 179
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1473,6 +1474,10 @@ struct kvm_enc_region {
 /* Available with KVM_CAP_ARM_SVE */
 #define KVM_ARM_VCPU_FINALIZE	  _IOW(KVMIO,  0xc2, int)
 
+/* Available with  KVM_CAP_S390_VCPU_RESETS */
+#define KVM_S390_NORMAL_RESET	_IO(KVMIO,   0xc3)
+#define KVM_S390_CLEAR_RESET	_IO(KVMIO,   0xc4)
+
 /* Secure Encrypted Virtualization command */
 enum sev_cmd_id {
 	/* Guest initialization commands */

target/s390x/cpu.c

@@ -78,13 +78,13 @@ static void s390_cpu_load_normal(CPUState *s)
     S390CPU *cpu = S390_CPU(s);
     uint64_t spsw = ldq_phys(s->as, 0);
 
-    cpu->env.psw.mask = spsw & 0xffffffff80000000ULL;
+    cpu->env.psw.mask = spsw & PSW_MASK_SHORT_CTRL;
     /*
      * Invert short psw indication, so SIE will report a specification
      * exception if it was not set.
      */
     cpu->env.psw.mask ^= PSW_MASK_SHORTPSW;
-    cpu->env.psw.addr = spsw & 0x7fffffffULL;
+    cpu->env.psw.addr = spsw & PSW_MASK_SHORT_ADDR;
 
     s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
 }
@@ -144,8 +144,18 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
     }
 
     /* Reset state inside the kernel that we cannot access yet from QEMU. */
-    if (kvm_enabled() && type != S390_CPU_RESET_NORMAL) {
+    if (kvm_enabled()) {
-        kvm_s390_reset_vcpu(cpu);
+        switch (type) {
+        case S390_CPU_RESET_CLEAR:
+            kvm_s390_reset_vcpu_clear(cpu);
+            break;
+        case S390_CPU_RESET_INITIAL:
+            kvm_s390_reset_vcpu_initial(cpu);
+            break;
+        case S390_CPU_RESET_NORMAL:
+            kvm_s390_reset_vcpu_normal(cpu);
+            break;
+        }
     }
 }
 

target/s390x/cpu.h

@@ -276,7 +276,8 @@ extern const VMStateDescription vmstate_s390_cpu;
 #define PSW_MASK_RI             0x0000008000000000ULL
 #define PSW_MASK_64             0x0000000100000000ULL
 #define PSW_MASK_32             0x0000000080000000ULL
-#define PSW_MASK_ESA_ADDR       0x000000007fffffffULL
+#define PSW_MASK_SHORT_ADDR     0x000000007fffffffULL
+#define PSW_MASK_SHORT_CTRL     0xffffffff80000000ULL
 
 #undef PSW_ASC_PRIMARY
 #undef PSW_ASC_ACCREG

target/s390x/helper.c

@@ -89,7 +89,7 @@ hwaddr s390_cpu_get_phys_addr_debug(CPUState *cs, vaddr vaddr)
 static inline bool is_special_wait_psw(uint64_t psw_addr)
 {
     /* signal quiesce */
-    return psw_addr == 0xfffUL;
+    return (psw_addr & 0xfffUL) == 0xfffUL;
 }
 
 void s390_handle_wait(S390CPU *cpu)

target/s390x/kvm-stub.c

@@ -83,7 +83,15 @@ void kvm_s390_cmma_reset(void)
 {
 }
 
-void kvm_s390_reset_vcpu(S390CPU *cpu)
+void kvm_s390_reset_vcpu_initial(S390CPU *cpu)
+{
+}
+
+void kvm_s390_reset_vcpu_clear(S390CPU *cpu)
+{
+}
+
+void kvm_s390_reset_vcpu_normal(S390CPU *cpu)
 {
 }
 

target/s390x/kvm.c

@@ -151,6 +151,7 @@ static int cap_s390_irq;
 static int cap_ri;
 static int cap_gs;
 static int cap_hpage_1m;
+static int cap_vcpu_resets;
 
 static int active_cmma;
 
@@ -342,6 +343,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
     cap_async_pf = kvm_check_extension(s, KVM_CAP_ASYNC_PF);
     cap_mem_op = kvm_check_extension(s, KVM_CAP_S390_MEM_OP);
     cap_s390_irq = kvm_check_extension(s, KVM_CAP_S390_INJECT_IRQ);
+    cap_vcpu_resets = kvm_check_extension(s, KVM_CAP_S390_VCPU_RESETS);
 
     if (!kvm_check_extension(s, KVM_CAP_S390_GMAP)
         || !kvm_check_extension(s, KVM_CAP_S390_COW)) {
@@ -406,17 +408,41 @@ int kvm_arch_destroy_vcpu(CPUState *cs)
     return 0;
 }
 
-void kvm_s390_reset_vcpu(S390CPU *cpu)
+static void kvm_s390_reset_vcpu(S390CPU *cpu, unsigned long type)
 {
     CPUState *cs = CPU(cpu);
 
-    /* The initial reset call is needed here to reset in-kernel
+    /*
-     * vcpu data that we can't access directly from QEMU
+     * The reset call is needed here to reset in-kernel vcpu data that
-     * (i.e. with older kernels which don't support sync_regs/ONE_REG).
+     * we can't access directly from QEMU (i.e. with older kernels
-     * Before this ioctl cpu_synchronize_state() is called in common kvm
+     * which don't support sync_regs/ONE_REG).  Before this ioctl
-     * code (kvm-all) */
+     * cpu_synchronize_state() is called in common kvm code
-    if (kvm_vcpu_ioctl(cs, KVM_S390_INITIAL_RESET, NULL)) {
+     * (kvm-all).
-        error_report("Initial CPU reset failed on CPU %i", cs->cpu_index);
+     */
+    if (kvm_vcpu_ioctl(cs, type)) {
+        error_report("CPU reset failed on CPU %i type %lx",
+                     cs->cpu_index, type);
+    }
+}
+
+void kvm_s390_reset_vcpu_initial(S390CPU *cpu)
+{
+    kvm_s390_reset_vcpu(cpu, KVM_S390_INITIAL_RESET);
+}
+
+void kvm_s390_reset_vcpu_clear(S390CPU *cpu)
+{
+    if (cap_vcpu_resets) {
+        kvm_s390_reset_vcpu(cpu, KVM_S390_CLEAR_RESET);
+    } else {
+        kvm_s390_reset_vcpu(cpu, KVM_S390_INITIAL_RESET);
+    }
+}
+
+void kvm_s390_reset_vcpu_normal(S390CPU *cpu)
+{
+    if (cap_vcpu_resets) {
+        kvm_s390_reset_vcpu(cpu, KVM_S390_NORMAL_RESET);
     }
 }
 

target/s390x/kvm_s390x.h

@@ -34,7 +34,9 @@ int kvm_s390_assign_subch_ioeventfd(EventNotifier *notifier, uint32_t sch,
                                     int vq, bool assign);
 int kvm_s390_cmma_active(void);
 void kvm_s390_cmma_reset(void);
-void kvm_s390_reset_vcpu(S390CPU *cpu);
+void kvm_s390_reset_vcpu_clear(S390CPU *cpu);
+void kvm_s390_reset_vcpu_normal(S390CPU *cpu);
+void kvm_s390_reset_vcpu_initial(S390CPU *cpu);
 int kvm_s390_set_mem_limit(uint64_t new_limit, uint64_t *hw_limit);
 void kvm_s390_set_max_pagesize(uint64_t pagesize, Error **errp);
 void kvm_s390_crypto_reset(void);

target/s390x/translate.c

@@ -3874,7 +3874,7 @@ static DisasJumpType op_rosbg(DisasContext *s, DisasOps *o)
 
     /* Operate.  */
     switch (s->fields.op2) {
-    case 0x55: /* AND */
+    case 0x54: /* AND */
         tcg_gen_ori_i64(o->in2, o->in2, ~mask);
         tcg_gen_and_i64(o->out, o->out, o->in2);
         break;