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>
This commit is contained in:
commit
430f63e250
|
@ -1259,7 +1259,7 @@ S: Supported
|
||||||
F: hw/s390x/ipl.*
|
F: hw/s390x/ipl.*
|
||||||
F: pc-bios/s390-ccw/
|
F: pc-bios/s390-ccw/
|
||||||
F: pc-bios/s390-ccw.img
|
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
|
T: git https://github.com/borntraeger/qemu.git s390-next
|
||||||
L: qemu-s390x@nongnu.org
|
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-device.h
|
||||||
F: include/hw/s390x/ap-bridge.h
|
F: include/hw/s390x/ap-bridge.h
|
||||||
F: hw/vfio/ap.c
|
F: hw/vfio/ap.c
|
||||||
F: docs/vfio-ap.txt
|
F: docs/system/vfio-ap.rst
|
||||||
L: qemu-s390x@nongnu.org
|
L: qemu-s390x@nongnu.org
|
||||||
|
|
||||||
vhost
|
vhost
|
||||||
|
|
|
@ -25,3 +25,4 @@ Contents:
|
||||||
tcg-plugins
|
tcg-plugins
|
||||||
bitops
|
bitops
|
||||||
reset
|
reset
|
||||||
|
s390-dasd-ipl
|
||||||
|
|
|
@ -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.
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
and the TIC (Transfer In Channel) will transfer control to the channel
|
||||||
program contained in the IPL2 data. The TIC channel command is the
|
program contained in the IPL2 data. The TIC channel command is the
|
||||||
equivalent of a branch/jump/goto instruction for channel programs.
|
equivalent of a branch/jump/goto instruction for channel programs.
|
||||||
|
|
||||||
NOTE: The ccws in IPL1 are defined by the architecture to be format 0.
|
NOTE: The ccws in IPL1 are defined by the architecture to be format 0.
|
||||||
|
|
||||||
3. Execute IPL2.
|
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
|
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
|
control over to the guest operating system. At this point the guest
|
||||||
operating system is entirely responsible for loading any more data it might
|
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
|
address points to the guest operating system code to execute at the end of
|
||||||
the IPL/boot process.
|
the IPL/boot process.
|
||||||
|
|
||||||
NOTE: The ccws in IPL2 are defined by the architecture to be format 0.
|
NOTE: The ccws in IPL2 are defined by the architecture to be format 0.
|
||||||
|
|
||||||
4. Start executing the guest operating system.
|
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
|
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
|
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
|
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
|
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
|
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"
|
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
|
In theory we should merely have to do the following to IPL/boot a guest
|
||||||
operating system from a DASD device:
|
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
|
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:
|
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
|
transfers control to another channel program segment immediately after reading
|
||||||
it from the disk. So we need to be able to handle this case.
|
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
|
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
|
procedure we defined in the preceding section. So we compensate by doing the
|
||||||
following.
|
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
|
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
|
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
|
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
|
both IPL1 and IPL2 as part of the same channel program we must manually set
|
||||||
the position.
|
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.
|
This address is where the IPL2 channel program starts.
|
||||||
|
|
||||||
Now IPL2 is loaded into memory somewhere, and we know the address.
|
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
|
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
|
that detects a READ immediately followed by a TIC and breaks the ccw chain
|
||||||
|
@ -126,8 +130,9 @@ following.
|
||||||
channel program from executing properly.
|
channel program from executing properly.
|
||||||
|
|
||||||
Now the operating system code is loaded somewhere in guest memory and the psw
|
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.
|
system.
|
||||||
|
|
||||||
7. LPSW 0x0.
|
6. LPSW ``0x0``
|
||||||
|
|
||||||
LPSW transfers control to the guest operating system and we're done.
|
LPSW transfers control to the guest operating system and we're done.
|
|
@ -15,3 +15,4 @@ Contents:
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
qemu-block-drivers
|
qemu-block-drivers
|
||||||
|
vfio-ap
|
||||||
|
|
|
@ -1,17 +1,11 @@
|
||||||
Adjunct Processor (AP) Device
|
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
|
The IBM Adjunct Processor (AP) Cryptographic Facility is comprised
|
||||||
of three AP instructions and from 1 to 256 PCIe cryptographic adapter cards.
|
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
|
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
|
describes how those cards may be made available to KVM guests using the
|
||||||
VFIO mediated device framework.
|
VFIO mediated device framework.
|
||||||
|
|
||||||
AP Architectural Overview:
|
AP Architectural Overview
|
||||||
=========================
|
-------------------------
|
||||||
|
|
||||||
In order understand the terminology used in the rest of this document, let's
|
In order understand the terminology used in the rest of this document, let's
|
||||||
start with some definitions:
|
start with some definitions:
|
||||||
|
|
||||||
|
@ -75,7 +70,8 @@ start with some definitions:
|
||||||
must be one of the control domains.
|
must be one of the control domains.
|
||||||
|
|
||||||
Start Interpretive Execution (SIE) Instruction
|
Start Interpretive Execution (SIE) Instruction
|
||||||
==============================================
|
----------------------------------------------
|
||||||
|
|
||||||
A KVM guest is started by executing the Start Interpretive Execution (SIE)
|
A KVM guest is started by executing the Start Interpretive Execution (SIE)
|
||||||
instruction. The SIE state description is a control block that contains the
|
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
|
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
|
on the adapter card for each of its domains - so each APQN must be assigned to
|
||||||
at most one guest or the linux host.
|
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:
|
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
|
This is an invalid configuration because both guests have access to
|
||||||
APQN (1,6).
|
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
|
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
|
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
|
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
|
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
|
/sys/bus/ap
|
||||||
... [devices]
|
... [devices]
|
||||||
|
@ -155,13 +173,16 @@ LPAR and create the following in sysfs:
|
||||||
...... ...
|
...... ...
|
||||||
|
|
||||||
Where:
|
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
|
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
|
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
|
/sys/bus/ap
|
||||||
... [devices]
|
... [devices]
|
||||||
|
@ -177,7 +198,7 @@ host system would look like this:
|
||||||
...... card06
|
...... card06
|
||||||
|
|
||||||
A set of default device drivers are also created to control each type of AP
|
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
|
/sys/bus/ap
|
||||||
... [drivers]
|
... [drivers]
|
||||||
|
@ -193,30 +214,31 @@ device that can be assigned to the LPAR on which a linux host is running:
|
||||||
coprocessor cards
|
coprocessor cards
|
||||||
|
|
||||||
Binding AP devices to device drivers
|
Binding AP devices to device drivers
|
||||||
------------------------------------
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
There are two sysfs files that specify bitmasks marking a subset of the APQN
|
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
|
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
|
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/apmask
|
||||||
/sys/bus/ap/aqmask
|
/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
|
(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
|
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
|
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
|
queue device drivers; otherwise, the APID is usable by the vfio_ap
|
||||||
device driver.
|
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
|
(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
|
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
|
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
|
queue device drivers; otherwise, the APQI is usable by the vfio_ap device
|
||||||
driver.
|
driver.
|
||||||
|
|
||||||
Take, for example, the following mask:
|
Take, for example, the following mask::
|
||||||
|
|
||||||
0x7dffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
|
0x7dffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
|
||||||
|
|
||||||
|
@ -240,29 +262,30 @@ driver(s). The sysfs locations of the masks are:
|
||||||
* An absolute hex string starting with 0x - like "0x12345678" - sets
|
* An absolute hex string starting with 0x - like "0x12345678" - sets
|
||||||
the mask. If the given string is shorter than the mask, it is padded
|
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
|
with 0s on the right; for example, specifying a mask value of 0x41 is
|
||||||
the same as specifying:
|
the same as specifying::
|
||||||
|
|
||||||
0x4100000000000000000000000000000000000000000000000000000000000000
|
0x4100000000000000000000000000000000000000000000000000000000000000
|
||||||
|
|
||||||
Keep in mind that the mask reads from left to right (i.e., most
|
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
|
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
|
If the string is longer than the mask, the operation is terminated with
|
||||||
an error (EINVAL).
|
an error (EINVAL).
|
||||||
|
|
||||||
* Individual bits in the mask can be switched on and off by specifying
|
* 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
|
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
|
"+0" switches bit 0 on
|
||||||
"-13" switches bit 13 off
|
"-13" switches bit 13 off
|
||||||
"+0x41" switches bit 65 on
|
"+0x41" switches bit 65 on
|
||||||
"-0xff" switches bit 255 off
|
"-0xff" switches bit 255 off
|
||||||
|
|
||||||
The following example:
|
The following example::
|
||||||
|
|
||||||
+0,-6,+0x47,-0xf0
|
+0,-6,+0x47,-0xf0
|
||||||
|
|
||||||
Switches bits 0 and 71 (0x47) on
|
Switches bits 0 and 71 (0x47) on
|
||||||
|
@ -272,31 +295,34 @@ driver(s). The sysfs locations of the masks are:
|
||||||
the operation.
|
the operation.
|
||||||
|
|
||||||
2. The masks can also be changed at boot time via parameters on the kernel
|
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
|
ap.apmask=0xffff ap.aqmask=0x40
|
||||||
|
|
||||||
This would create the following masks:
|
This would create the following masks:
|
||||||
|
|
||||||
apmask:
|
apmask::
|
||||||
|
|
||||||
0xffff000000000000000000000000000000000000000000000000000000000000
|
0xffff000000000000000000000000000000000000000000000000000000000000
|
||||||
|
|
||||||
aqmask:
|
aqmask::
|
||||||
|
|
||||||
0x4000000000000000000000000000000000000000000000000000000000000000
|
0x4000000000000000000000000000000000000000000000000000000000000000
|
||||||
|
|
||||||
Resulting in these two pools:
|
Resulting in these two pools::
|
||||||
|
|
||||||
default drivers pool: adapter 0-15, domain 1
|
default drivers pool: adapter 0-15, domain 1
|
||||||
alternate drivers pool: adapter 16-255, domains 0, 2-255
|
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
|
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
|
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
|
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
|
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
|
/sys/devices
|
||||||
... [vfio_ap]
|
... [vfio_ap]
|
||||||
|
@ -307,16 +333,18 @@ creating mediated matrix devices is created:
|
||||||
............... [devices]
|
............... [devices]
|
||||||
|
|
||||||
A mediated AP matrix device is created by writing a UUID to the attribute file
|
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
|
uuidgen > create
|
||||||
|
|
||||||
or
|
or
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
echo $uuid > create
|
echo $uuid > create
|
||||||
|
|
||||||
When a mediated AP matrix device is created, a sysfs directory named after
|
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
|
/sys/devices
|
||||||
... [vfio_ap]
|
... [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
|
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
|
matrix device's sysfs directory to configure an AP matrix for the
|
||||||
KVM guest:
|
KVM guest::
|
||||||
|
|
||||||
/sys/devices
|
/sys/devices
|
||||||
... [vfio_ap]
|
... [vfio_ap]
|
||||||
|
@ -347,13 +375,13 @@ KVM guest:
|
||||||
..................... unassign_control_domain
|
..................... unassign_control_domain
|
||||||
..................... unassign_domain
|
..................... unassign_domain
|
||||||
|
|
||||||
assign_adapter
|
``assign_adapter``
|
||||||
To assign an AP adapter to the mediated matrix device, its APID is written
|
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
|
than one adapter. The APID may be specified using conventional semantics
|
||||||
as a decimal, hexadecimal, or octal number. For example, to assign adapters
|
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
|
4, 5 and 16 to a mediated matrix device in decimal, hexadecimal and octal
|
||||||
respectively:
|
respectively::
|
||||||
|
|
||||||
echo 4 > assign_adapter
|
echo 4 > assign_adapter
|
||||||
echo 0x5 > assign_adapter
|
echo 0x5 > assign_adapter
|
||||||
|
@ -373,22 +401,22 @@ assign_adapter
|
||||||
APQNs are bound to the driver, the operation will terminate with an
|
APQNs are bound to the driver, the operation will terminate with an
|
||||||
error (EADDRNOTAVAIL).
|
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
|
previously assigned domains can be assigned to another mediated matrix
|
||||||
device. If an APQN is assigned to another mediated matrix device, the
|
device. If an APQN is assigned to another mediated matrix device, the
|
||||||
operation will terminate with an error (EADDRINUSE).
|
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.
|
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
|
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
|
usage domain. The domain number is specified using conventional semantics as
|
||||||
a decimal, hexadecimal, or octal number. For example, to assign usage domains
|
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
|
4, 8, and 71 to a mediated matrix device in decimal, hexadecimal and octal
|
||||||
respectively:
|
respectively::
|
||||||
|
|
||||||
echo 4 > assign_domain
|
echo 4 > assign_domain
|
||||||
echo 0x8 > assign_domain
|
echo 0x8 > assign_domain
|
||||||
|
@ -408,23 +436,23 @@ assign_domain
|
||||||
APQNs are bound to the driver, the operation will terminate with an
|
APQNs are bound to the driver, the operation will terminate with an
|
||||||
error (EADDRNOTAVAIL).
|
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
|
of the previously assigned adapters can be assigned to another mediated
|
||||||
matrix device. If an APQN is assigned to another mediated matrix device,
|
matrix device. If an APQN is assigned to another mediated matrix device,
|
||||||
the operation will terminate with an error (EADDRINUSE).
|
the operation will terminate with an error (EADDRINUSE).
|
||||||
|
|
||||||
unassign_domain
|
``unassign_domain``
|
||||||
To unassign a usage domain, the domain number is written into the
|
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.
|
one usage domain.
|
||||||
|
|
||||||
assign_control_domain
|
``assign_control_domain``
|
||||||
To assign a control domain, the domain number is written into the
|
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
|
assign more than one control domain. The domain number may be specified using
|
||||||
conventional semantics as a decimal, hexadecimal, or octal number. For
|
conventional semantics as a decimal, hexadecimal, or octal number. For
|
||||||
example, to assign control domains 4, 8, and 71 to a mediated matrix device
|
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 4 > assign_domain
|
||||||
echo 0x8 > 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
|
allowed by the machine model. If a control domain number higher than the
|
||||||
maximum is specified, the operation will terminate with an error (ENODEV).
|
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
|
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.
|
one control domain.
|
||||||
|
|
||||||
Notes: No changes to the AP matrix will be allowed while a guest using
|
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,
|
the mediated matrix device is running. Attempts to assign an adapter,
|
||||||
domain or control domain will be rejected and an error (EBUSY) returned.
|
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
|
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
|
-device vfio_ap,sysfsdev=$path-to-mdev
|
||||||
|
|
||||||
The sysfsdev parameter specifies the path to the mediated matrix device.
|
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/devices/vfio_ap/matrix/$uuid
|
||||||
/sys/bus/mdev/devices/$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
|
When the linux guest is started, the guest will open the mediated
|
||||||
matrix device's file descriptor to get information about the mediated matrix
|
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
|
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
|
via the mediated matrix device's sysfs attribute files. Programs running on the
|
||||||
linux guest will then:
|
linux guest will then:
|
||||||
|
@ -486,19 +515,21 @@ facilities:
|
||||||
The AP facilities feature indicates that AP facilities are installed on the
|
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
|
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
|
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
|
qemu-system-s390x -cpu $model,ap=on|off
|
||||||
|
|
||||||
Where:
|
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).
|
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
|
(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.
|
for the guest, or the guest will fail to start.
|
||||||
|
|
||||||
2. Query Configuration Information (QCI) facility
|
2. Query Configuration Information (QCI) facility
|
||||||
|
@ -507,20 +538,22 @@ facilities:
|
||||||
configuration of the AP facilities. This facility will be available
|
configuration of the AP facilities. This facility will be available
|
||||||
only if the QCI facility is installed on the host system. The feature is
|
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
|
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
|
qemu-system-s390x -cpu $model,apqci=on|off
|
||||||
|
|
||||||
Where:
|
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
|
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
|
will be allowed to start. It makes no sense to have QCI
|
||||||
installed if the AP facilities are not; this is considered
|
installed if the AP facilities are not; this is considered
|
||||||
an invalid configuration.
|
an invalid configuration.
|
||||||
|
@ -535,22 +568,24 @@ facilities:
|
||||||
AP facilities available for a given AP queue. This facility will be available
|
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
|
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
|
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
|
qemu-system-s390x -cpu $model,apft=on|off
|
||||||
|
|
||||||
Where:
|
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).
|
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
|
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.
|
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
|
will be allowed to start. It makes no sense to have APFT
|
||||||
installed if the AP facilities are not; this is considered
|
installed if the AP facilities are not; this is considered
|
||||||
an invalid configuration.
|
an invalid configuration.
|
||||||
|
@ -561,22 +596,23 @@ facilities:
|
||||||
for guest usage, no AP devices can be made accessible to a
|
for guest usage, no AP devices can be made accessible to a
|
||||||
guest started without APFT installed.
|
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
|
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
|
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
|
to the bus already, whether via the QEMU command line or a prior hot plug
|
||||||
action.
|
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"
|
(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.
|
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
|
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
|
scan, so there may be a short delay before the AP devices are accessible on the
|
||||||
guest.
|
guest.
|
||||||
|
|
||||||
|
@ -587,37 +623,39 @@ The command will fail if:
|
||||||
* The CPU model features for controlling guest access to AP facilities are not
|
* The CPU model features for controlling guest access to AP facilities are not
|
||||||
enabled (see 'CPU model features' subsection in the previous section).
|
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
|
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
|
has been attached to the virtual machine's ap-bus via the QEMU command line
|
||||||
or a prior hot plug action.
|
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"
|
(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.
|
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,
|
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
|
so there may be a short delay before the AP devices are no longer accessible by
|
||||||
the guest.
|
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
|
does not match the value specified when the vfio-ap device was attached to
|
||||||
the virtual machine's ap-bus.
|
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
|
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
|
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
|
three guests such that executing the lszcrypt command on the guests would
|
||||||
look like this:
|
look like this:
|
||||||
|
|
||||||
Guest1
|
Guest1::
|
||||||
------
|
|
||||||
CARD.DOMAIN TYPE MODE
|
CARD.DOMAIN TYPE MODE
|
||||||
------------------------------
|
------------------------------
|
||||||
05 CEX5C CCA-Coproc
|
05 CEX5C CCA-Coproc
|
||||||
|
@ -627,16 +665,16 @@ CARD.DOMAIN TYPE MODE
|
||||||
06.0004 CEX5A Accelerator
|
06.0004 CEX5A Accelerator
|
||||||
06.00ab CEX5C CCA-Coproc
|
06.00ab CEX5C CCA-Coproc
|
||||||
|
|
||||||
Guest2
|
Guest2::
|
||||||
------
|
|
||||||
CARD.DOMAIN TYPE MODE
|
CARD.DOMAIN TYPE MODE
|
||||||
------------------------------
|
------------------------------
|
||||||
05 CEX5A Accelerator
|
05 CEX5A Accelerator
|
||||||
05.0047 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
|
CARD.DOMAIN TYPE MODE
|
||||||
------------------------------
|
------------------------------
|
||||||
06 CEX5A Accelerator
|
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
|
1. Install the vfio_ap module on the linux host. The dependency chain for the
|
||||||
vfio_ap module is:
|
vfio_ap module is:
|
||||||
|
|
||||||
* iommu
|
* iommu
|
||||||
* s390
|
* s390
|
||||||
* zcrypt
|
* zcrypt
|
||||||
|
@ -657,6 +696,7 @@ These are the steps:
|
||||||
|
|
||||||
To build the vfio_ap module, the kernel build must be configured with the
|
To build the vfio_ap module, the kernel build must be configured with the
|
||||||
following Kconfig elements selected:
|
following Kconfig elements selected:
|
||||||
|
|
||||||
* IOMMU_SUPPORT
|
* IOMMU_SUPPORT
|
||||||
* S390
|
* S390
|
||||||
* ZCRYPT
|
* ZCRYPT
|
||||||
|
@ -666,7 +706,7 @@ These are the steps:
|
||||||
* VFIO_MDEV_DEVICE
|
* VFIO_MDEV_DEVICE
|
||||||
* KVM
|
* 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
|
-> Device Drivers
|
||||||
-> IOMMU Hardware Support
|
-> IOMMU Hardware Support
|
||||||
select S390 AP IOMMU 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,
|
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,
|
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
|
the corresponding APQNs must be removed from the default queue drivers pool
|
||||||
as follows:
|
as follows::
|
||||||
|
|
||||||
echo -5,-6 > /sys/bus/ap/apmask
|
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,
|
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
|
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
|
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
|
/sys/bus/ap
|
||||||
... [drivers]
|
... [drivers]
|
||||||
|
@ -712,7 +752,7 @@ These are the steps:
|
||||||
The administrator, therefore, must take care to secure only AP queues that
|
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
|
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,
|
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
|
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
|
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
|
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/
|
/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
|
||||||
uuidgen > create
|
uuidgen > create
|
||||||
|
@ -737,49 +777,51 @@ These are the steps:
|
||||||
|
|
||||||
or
|
or
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
echo $uuid1 > create
|
echo $uuid1 > create
|
||||||
echo $uuid2 > create
|
echo $uuid2 > create
|
||||||
echo $uuid3 > create
|
echo $uuid3 > create
|
||||||
|
|
||||||
This will create three mediated devices in the [devices] subdirectory named
|
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,
|
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/
|
/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
|
4. The administrator now needs to configure the matrixes for the mediated
|
||||||
devices $uuid1 (for Guest1), $uuid2 (for Guest2) and $uuid3 (for Guest3).
|
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 5 > assign_adapter
|
||||||
echo 6 > assign_adapter
|
echo 6 > assign_adapter
|
||||||
|
@ -790,59 +832,56 @@ These are the steps:
|
||||||
sysfs file.
|
sysfs file.
|
||||||
|
|
||||||
If a mistake is made configuring an adapter, domain or control domain,
|
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.
|
control domain.
|
||||||
|
|
||||||
To display the matrix configuration for Guest1:
|
To display the matrix configuration for Guest1::
|
||||||
|
|
||||||
cat matrix
|
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
|
the adapter number and yyyy is the domain number. The output for Guest1
|
||||||
will look like this:
|
will look like this::
|
||||||
|
|
||||||
05.0004
|
05.0004
|
||||||
05.00ab
|
05.00ab
|
||||||
06.0004
|
06.0004
|
||||||
06.00ab
|
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 5 > assign_adapter
|
||||||
echo 0x47 > assign_domain
|
echo 0x47 > assign_domain
|
||||||
echo 0xff > 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 6 > assign_adapter
|
||||||
echo 0x47 > assign_domain
|
echo 0x47 > assign_domain
|
||||||
echo 0xff > 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.
|
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/
|
/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
|
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.
|
the pool of adapters and queues reserved for use by the default drivers.
|
||||||
|
|
||||||
Limitations
|
Limitations
|
||||||
===========
|
-----------
|
||||||
|
|
||||||
* The KVM/kernel interfaces do not provide a way to prevent restoring an APQN
|
* 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
|
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
|
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.
|
device, such as a private key configured specifically for the guest.
|
||||||
|
|
||||||
* Dynamically assigning AP resources to or unassigning AP resources from a
|
* 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.
|
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
|
* 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
|
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.)
|
|
@ -179,7 +179,7 @@ static void s390_ipl_realize(DeviceState *dev, Error **errp)
|
||||||
/* if not Linux load the address of the (short) IPL PSW */
|
/* if not Linux load the address of the (short) IPL PSW */
|
||||||
ipl_psw = rom_ptr(4, 4);
|
ipl_psw = rom_ptr(4, 4);
|
||||||
if (ipl_psw) {
|
if (ipl_psw) {
|
||||||
pentry = be32_to_cpu(*ipl_psw) & 0x7fffffffUL;
|
pentry = be32_to_cpu(*ipl_psw) & PSW_MASK_SHORT_ADDR;
|
||||||
} else {
|
} else {
|
||||||
error_setg(&err, "Could not get IPL PSW");
|
error_setg(&err, "Could not get IPL PSW");
|
||||||
goto error;
|
goto error;
|
||||||
|
|
|
@ -409,6 +409,30 @@ extern "C" {
|
||||||
#define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
|
#define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
|
||||||
#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
|
#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
|
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
|
||||||
*
|
*
|
||||||
|
|
|
@ -593,6 +593,9 @@ struct ethtool_pauseparam {
|
||||||
* @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
|
* @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
|
||||||
* @ETH_SS_PHY_STATS: Statistic names, for use with %ETHTOOL_GPHYSTATS
|
* @ETH_SS_PHY_STATS: Statistic names, for use with %ETHTOOL_GPHYSTATS
|
||||||
* @ETH_SS_PHY_TUNABLES: PHY tunable names
|
* @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 {
|
enum ethtool_stringset {
|
||||||
ETH_SS_TEST = 0,
|
ETH_SS_TEST = 0,
|
||||||
|
@ -604,6 +607,12 @@ enum ethtool_stringset {
|
||||||
ETH_SS_TUNABLES,
|
ETH_SS_TUNABLES,
|
||||||
ETH_SS_PHY_STATS,
|
ETH_SS_PHY_STATS,
|
||||||
ETH_SS_PHY_TUNABLES,
|
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_MAGICSECURE (1 << 6) /* only meaningful if WAKE_MAGIC */
|
||||||
#define WAKE_FILTER (1 << 7)
|
#define WAKE_FILTER (1 << 7)
|
||||||
|
|
||||||
|
#define WOL_MODE_COUNT 8
|
||||||
|
|
||||||
/* L2-L4 network traffic flow types */
|
/* L2-L4 network traffic flow types */
|
||||||
#define TCP_V4_FLOW 0x01 /* hash or spec (tcp_ip4_spec) */
|
#define TCP_V4_FLOW 0x01 /* hash or spec (tcp_ip4_spec) */
|
||||||
#define UDP_V4_FLOW 0x02 /* hash or spec (udp_ip4_spec) */
|
#define UDP_V4_FLOW 0x02 /* hash or spec (udp_ip4_spec) */
|
||||||
|
|
|
@ -31,6 +31,7 @@ struct input_event {
|
||||||
unsigned long __sec;
|
unsigned long __sec;
|
||||||
#if defined(__sparc__) && defined(__arch64__)
|
#if defined(__sparc__) && defined(__arch64__)
|
||||||
unsigned int __usec;
|
unsigned int __usec;
|
||||||
|
unsigned int __pad;
|
||||||
#else
|
#else
|
||||||
unsigned long __usec;
|
unsigned long __usec;
|
||||||
#endif
|
#endif
|
||||||
|
|
|
@ -676,6 +676,7 @@
|
||||||
#define PCI_EXP_LNKCTL2_TLS_32_0GT 0x0005 /* Supported Speed 32GT/s */
|
#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_ENTER_COMP 0x0010 /* Enter Compliance */
|
||||||
#define PCI_EXP_LNKCTL2_TX_MARGIN 0x0380 /* Transmit Margin */
|
#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_EXP_LNKSTA2 50 /* Link Status 2 */
|
||||||
#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 52 /* v2 endpoints with link end here */
|
#define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 52 /* v2 endpoints with link end here */
|
||||||
#define PCI_EXP_SLTCAP2 52 /* Slot Capabilities 2 */
|
#define PCI_EXP_SLTCAP2 52 /* Slot Capabilities 2 */
|
||||||
|
|
|
@ -390,5 +390,7 @@
|
||||||
#define __NR_fspick (__NR_SYSCALL_BASE + 433)
|
#define __NR_fspick (__NR_SYSCALL_BASE + 433)
|
||||||
#define __NR_pidfd_open (__NR_SYSCALL_BASE + 434)
|
#define __NR_pidfd_open (__NR_SYSCALL_BASE + 434)
|
||||||
#define __NR_clone3 (__NR_SYSCALL_BASE + 435)
|
#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 */
|
#endif /* _ASM_ARM_UNISTD_COMMON_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_CVAL ARM64_SYS_REG(3, 3, 14, 2, 2)
|
||||||
#define KVM_REG_ARM_PTIMER_CNT ARM64_SYS_REG(3, 3, 14, 0, 1)
|
#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_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_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 */
|
/* KVM-as-firmware specific pseudo-registers */
|
||||||
#define KVM_REG_ARM_FW (0x0014 << KVM_REG_ARM_COPROC_SHIFT)
|
#define KVM_REG_ARM_FW (0x0014 << KVM_REG_ARM_COPROC_SHIFT)
|
||||||
|
|
|
@ -19,5 +19,6 @@
|
||||||
#define __ARCH_WANT_NEW_STAT
|
#define __ARCH_WANT_NEW_STAT
|
||||||
#define __ARCH_WANT_SET_GET_RLIMIT
|
#define __ARCH_WANT_SET_GET_RLIMIT
|
||||||
#define __ARCH_WANT_TIME32_SYSCALLS
|
#define __ARCH_WANT_TIME32_SYSCALLS
|
||||||
|
#define __ARCH_WANT_SYS_CLONE3
|
||||||
|
|
||||||
#include <asm-generic/unistd.h>
|
#include <asm-generic/unistd.h>
|
||||||
|
|
|
@ -11,6 +11,8 @@
|
||||||
#define PROT_WRITE 0x2 /* page can be written */
|
#define PROT_WRITE 0x2 /* page can be written */
|
||||||
#define PROT_EXEC 0x4 /* page can be executed */
|
#define PROT_EXEC 0x4 /* page can be executed */
|
||||||
#define PROT_SEM 0x8 /* page may be used for atomic ops */
|
#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_NONE 0x0 /* page can not be accessed */
|
||||||
#define PROT_GROWSDOWN 0x01000000 /* mprotect flag: extend change to start of growsdown vma */
|
#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 */
|
#define PROT_GROWSUP 0x02000000 /* mprotect flag: extend change to end of growsup vma */
|
||||||
|
|
|
@ -851,8 +851,13 @@ __SYSCALL(__NR_pidfd_open, sys_pidfd_open)
|
||||||
__SYSCALL(__NR_clone3, sys_clone3)
|
__SYSCALL(__NR_clone3, sys_clone3)
|
||||||
#endif
|
#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
|
#undef __NR_syscalls
|
||||||
#define __NR_syscalls 436
|
#define __NR_syscalls 439
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* 32 bit systems traditionally used different
|
* 32 bit systems traditionally used different
|
||||||
|
|
|
@ -365,6 +365,8 @@
|
||||||
#define __NR_fspick (__NR_Linux + 433)
|
#define __NR_fspick (__NR_Linux + 433)
|
||||||
#define __NR_pidfd_open (__NR_Linux + 434)
|
#define __NR_pidfd_open (__NR_Linux + 434)
|
||||||
#define __NR_clone3 (__NR_Linux + 435)
|
#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 */
|
#endif /* _ASM_MIPS_UNISTD_N32_H */
|
||||||
|
|
|
@ -341,6 +341,8 @@
|
||||||
#define __NR_fspick (__NR_Linux + 433)
|
#define __NR_fspick (__NR_Linux + 433)
|
||||||
#define __NR_pidfd_open (__NR_Linux + 434)
|
#define __NR_pidfd_open (__NR_Linux + 434)
|
||||||
#define __NR_clone3 (__NR_Linux + 435)
|
#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 */
|
#endif /* _ASM_MIPS_UNISTD_N64_H */
|
||||||
|
|
|
@ -411,6 +411,8 @@
|
||||||
#define __NR_fspick (__NR_Linux + 433)
|
#define __NR_fspick (__NR_Linux + 433)
|
||||||
#define __NR_pidfd_open (__NR_Linux + 434)
|
#define __NR_pidfd_open (__NR_Linux + 434)
|
||||||
#define __NR_clone3 (__NR_Linux + 435)
|
#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 */
|
#endif /* _ASM_MIPS_UNISTD_O32_H */
|
||||||
|
|
|
@ -418,6 +418,8 @@
|
||||||
#define __NR_fspick 433
|
#define __NR_fspick 433
|
||||||
#define __NR_pidfd_open 434
|
#define __NR_pidfd_open 434
|
||||||
#define __NR_clone3 435
|
#define __NR_clone3 435
|
||||||
|
#define __NR_openat2 437
|
||||||
|
#define __NR_pidfd_getfd 438
|
||||||
|
|
||||||
|
|
||||||
#endif /* _ASM_POWERPC_UNISTD_32_H */
|
#endif /* _ASM_POWERPC_UNISTD_32_H */
|
||||||
|
|
|
@ -390,6 +390,8 @@
|
||||||
#define __NR_fspick 433
|
#define __NR_fspick 433
|
||||||
#define __NR_pidfd_open 434
|
#define __NR_pidfd_open 434
|
||||||
#define __NR_clone3 435
|
#define __NR_clone3 435
|
||||||
|
#define __NR_openat2 437
|
||||||
|
#define __NR_pidfd_getfd 438
|
||||||
|
|
||||||
|
|
||||||
#endif /* _ASM_POWERPC_UNISTD_64_H */
|
#endif /* _ASM_POWERPC_UNISTD_64_H */
|
||||||
|
|
|
@ -408,5 +408,7 @@
|
||||||
#define __NR_fspick 433
|
#define __NR_fspick 433
|
||||||
#define __NR_pidfd_open 434
|
#define __NR_pidfd_open 434
|
||||||
#define __NR_clone3 435
|
#define __NR_clone3 435
|
||||||
|
#define __NR_openat2 437
|
||||||
|
#define __NR_pidfd_getfd 438
|
||||||
|
|
||||||
#endif /* _ASM_S390_UNISTD_32_H */
|
#endif /* _ASM_S390_UNISTD_32_H */
|
||||||
|
|
|
@ -356,5 +356,7 @@
|
||||||
#define __NR_fspick 433
|
#define __NR_fspick 433
|
||||||
#define __NR_pidfd_open 434
|
#define __NR_pidfd_open 434
|
||||||
#define __NR_clone3 435
|
#define __NR_clone3 435
|
||||||
|
#define __NR_openat2 437
|
||||||
|
#define __NR_pidfd_getfd 438
|
||||||
|
|
||||||
#endif /* _ASM_S390_UNISTD_64_H */
|
#endif /* _ASM_S390_UNISTD_64_H */
|
||||||
|
|
|
@ -426,5 +426,7 @@
|
||||||
#define __NR_fspick 433
|
#define __NR_fspick 433
|
||||||
#define __NR_pidfd_open 434
|
#define __NR_pidfd_open 434
|
||||||
#define __NR_clone3 435
|
#define __NR_clone3 435
|
||||||
|
#define __NR_openat2 437
|
||||||
|
#define __NR_pidfd_getfd 438
|
||||||
|
|
||||||
#endif /* _ASM_X86_UNISTD_32_H */
|
#endif /* _ASM_X86_UNISTD_32_H */
|
||||||
|
|
|
@ -348,5 +348,7 @@
|
||||||
#define __NR_fspick 433
|
#define __NR_fspick 433
|
||||||
#define __NR_pidfd_open 434
|
#define __NR_pidfd_open 434
|
||||||
#define __NR_clone3 435
|
#define __NR_clone3 435
|
||||||
|
#define __NR_openat2 437
|
||||||
|
#define __NR_pidfd_getfd 438
|
||||||
|
|
||||||
#endif /* _ASM_X86_UNISTD_64_H */
|
#endif /* _ASM_X86_UNISTD_64_H */
|
||||||
|
|
|
@ -301,6 +301,8 @@
|
||||||
#define __NR_fspick (__X32_SYSCALL_BIT + 433)
|
#define __NR_fspick (__X32_SYSCALL_BIT + 433)
|
||||||
#define __NR_pidfd_open (__X32_SYSCALL_BIT + 434)
|
#define __NR_pidfd_open (__X32_SYSCALL_BIT + 434)
|
||||||
#define __NR_clone3 (__X32_SYSCALL_BIT + 435)
|
#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_sigaction (__X32_SYSCALL_BIT + 512)
|
||||||
#define __NR_rt_sigreturn (__X32_SYSCALL_BIT + 513)
|
#define __NR_rt_sigreturn (__X32_SYSCALL_BIT + 513)
|
||||||
#define __NR_ioctl (__X32_SYSCALL_BIT + 514)
|
#define __NR_ioctl (__X32_SYSCALL_BIT + 514)
|
||||||
|
|
|
@ -1009,6 +1009,7 @@ struct kvm_ppc_resize_hpt {
|
||||||
#define KVM_CAP_PPC_GUEST_DEBUG_SSTEP 176
|
#define KVM_CAP_PPC_GUEST_DEBUG_SSTEP 176
|
||||||
#define KVM_CAP_ARM_NISV_TO_USER 177
|
#define KVM_CAP_ARM_NISV_TO_USER 177
|
||||||
#define KVM_CAP_ARM_INJECT_EXT_DABT 178
|
#define KVM_CAP_ARM_INJECT_EXT_DABT 178
|
||||||
|
#define KVM_CAP_S390_VCPU_RESETS 179
|
||||||
|
|
||||||
#ifdef KVM_CAP_IRQ_ROUTING
|
#ifdef KVM_CAP_IRQ_ROUTING
|
||||||
|
|
||||||
|
@ -1473,6 +1474,10 @@ struct kvm_enc_region {
|
||||||
/* Available with KVM_CAP_ARM_SVE */
|
/* Available with KVM_CAP_ARM_SVE */
|
||||||
#define KVM_ARM_VCPU_FINALIZE _IOW(KVMIO, 0xc2, int)
|
#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 */
|
/* Secure Encrypted Virtualization command */
|
||||||
enum sev_cmd_id {
|
enum sev_cmd_id {
|
||||||
/* Guest initialization commands */
|
/* Guest initialization commands */
|
||||||
|
|
|
@ -78,13 +78,13 @@ static void s390_cpu_load_normal(CPUState *s)
|
||||||
S390CPU *cpu = S390_CPU(s);
|
S390CPU *cpu = S390_CPU(s);
|
||||||
uint64_t spsw = ldq_phys(s->as, 0);
|
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
|
* Invert short psw indication, so SIE will report a specification
|
||||||
* exception if it was not set.
|
* exception if it was not set.
|
||||||
*/
|
*/
|
||||||
cpu->env.psw.mask ^= PSW_MASK_SHORTPSW;
|
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);
|
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. */
|
/* 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;
|
||||||
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
|
@ -276,7 +276,8 @@ extern const VMStateDescription vmstate_s390_cpu;
|
||||||
#define PSW_MASK_RI 0x0000008000000000ULL
|
#define PSW_MASK_RI 0x0000008000000000ULL
|
||||||
#define PSW_MASK_64 0x0000000100000000ULL
|
#define PSW_MASK_64 0x0000000100000000ULL
|
||||||
#define PSW_MASK_32 0x0000000080000000ULL
|
#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_PRIMARY
|
||||||
#undef PSW_ASC_ACCREG
|
#undef PSW_ASC_ACCREG
|
||||||
|
|
|
@ -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)
|
static inline bool is_special_wait_psw(uint64_t psw_addr)
|
||||||
{
|
{
|
||||||
/* signal quiesce */
|
/* signal quiesce */
|
||||||
return psw_addr == 0xfffUL;
|
return (psw_addr & 0xfffUL) == 0xfffUL;
|
||||||
}
|
}
|
||||||
|
|
||||||
void s390_handle_wait(S390CPU *cpu)
|
void s390_handle_wait(S390CPU *cpu)
|
||||||
|
|
|
@ -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)
|
||||||
{
|
{
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
|
@ -151,6 +151,7 @@ static int cap_s390_irq;
|
||||||
static int cap_ri;
|
static int cap_ri;
|
||||||
static int cap_gs;
|
static int cap_gs;
|
||||||
static int cap_hpage_1m;
|
static int cap_hpage_1m;
|
||||||
|
static int cap_vcpu_resets;
|
||||||
|
|
||||||
static int active_cmma;
|
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_async_pf = kvm_check_extension(s, KVM_CAP_ASYNC_PF);
|
||||||
cap_mem_op = kvm_check_extension(s, KVM_CAP_S390_MEM_OP);
|
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_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)
|
if (!kvm_check_extension(s, KVM_CAP_S390_GMAP)
|
||||||
|| !kvm_check_extension(s, KVM_CAP_S390_COW)) {
|
|| !kvm_check_extension(s, KVM_CAP_S390_COW)) {
|
||||||
|
@ -406,17 +408,41 @@ int kvm_arch_destroy_vcpu(CPUState *cs)
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
void kvm_s390_reset_vcpu(S390CPU *cpu)
|
static void kvm_s390_reset_vcpu(S390CPU *cpu, unsigned long type)
|
||||||
{
|
{
|
||||||
CPUState *cs = CPU(cpu);
|
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);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
|
@ -34,7 +34,9 @@ int kvm_s390_assign_subch_ioeventfd(EventNotifier *notifier, uint32_t sch,
|
||||||
int vq, bool assign);
|
int vq, bool assign);
|
||||||
int kvm_s390_cmma_active(void);
|
int kvm_s390_cmma_active(void);
|
||||||
void kvm_s390_cmma_reset(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);
|
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_set_max_pagesize(uint64_t pagesize, Error **errp);
|
||||||
void kvm_s390_crypto_reset(void);
|
void kvm_s390_crypto_reset(void);
|
||||||
|
|
|
@ -3874,7 +3874,7 @@ static DisasJumpType op_rosbg(DisasContext *s, DisasOps *o)
|
||||||
|
|
||||||
/* Operate. */
|
/* Operate. */
|
||||||
switch (s->fields.op2) {
|
switch (s->fields.op2) {
|
||||||
case 0x55: /* AND */
|
case 0x54: /* AND */
|
||||||
tcg_gen_ori_i64(o->in2, o->in2, ~mask);
|
tcg_gen_ori_i64(o->in2, o->in2, ~mask);
|
||||||
tcg_gen_and_i64(o->out, o->out, o->in2);
|
tcg_gen_and_i64(o->out, o->out, o->in2);
|
||||||
break;
|
break;
|
||||||
|
|
Loading…
Reference in a new issue