* [PATCH RFC 0/2] docs: rstfy some s390 docs
@ 2020-01-28 18:01 Cornelia Huck
2020-01-28 18:01 ` [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation Cornelia Huck
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Cornelia Huck @ 2020-01-28 18:01 UTC (permalink / raw)
To: Tony Krowiak, Jason J . Herne
Cc: Thomas Huth, Pierre Morel, Cornelia Huck, qemu-devel, Halil Pasic,
Christian Borntraeger, qemu-s390x
https://qemu.readthedocs.io/en/latest/index.html collects various
documents from the QEMU docs/ subdirectory; however, none of the
s390 files are currently included. Therefore, I set out to convert
the existing files to rst and hook them up.
s390-dasd-ipl was straightforward enough; I also found a numbering
issue.
vfio-ap was quite a bit more involved, but I hope I have produced
something readable (would benefit from some more review). I also
moved this into the system/ subdirectory; not sure if that is the
best resting place, but it seemed to be the most reasonable one.
Tested via running 'make html' and inspecting the output.
Branch: https://github.com/cohuck/qemu rstfy-s390
Cornelia Huck (2):
docs: rstfy s390 dasd ipl documentation
docs: rstfy vfio-ap documentation
MAINTAINERS | 4 +-
docs/devel/index.rst | 1 +
.../{s390-dasd-ipl.txt => s390-dasd-ipl.rst} | 65 +-
docs/system/index.rst | 1 +
docs/{vfio-ap.txt => system/vfio-ap.rst} | 755 +++++++++---------
5 files changed, 424 insertions(+), 402 deletions(-)
rename docs/devel/{s390-dasd-ipl.txt => s390-dasd-ipl.rst} (77%)
rename docs/{vfio-ap.txt => system/vfio-ap.rst} (56%)
--
2.21.1
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation 2020-01-28 18:01 [PATCH RFC 0/2] docs: rstfy some s390 docs Cornelia Huck @ 2020-01-28 18:01 ` Cornelia Huck 2020-02-05 11:02 ` Thomas Huth 2020-02-07 12:05 ` Peter Maydell 2020-01-28 18:01 ` [PATCH RFC 2/2] docs: rstfy vfio-ap documentation Cornelia Huck 2020-02-05 10:51 ` [PATCH RFC 0/2] docs: rstfy some s390 docs Cornelia Huck 2 siblings, 2 replies; 12+ messages in thread From: Cornelia Huck @ 2020-01-28 18:01 UTC (permalink / raw) To: Tony Krowiak, Jason J . Herne Cc: Thomas Huth, Pierre Morel, Cornelia Huck, qemu-devel, Halil Pasic, Christian Borntraeger, qemu-s390x While at it, also fix the numbering in 'What QEMU does'. Signed-off-by: Cornelia Huck <cohuck@redhat.com> --- MAINTAINERS | 2 +- docs/devel/index.rst | 1 + .../{s390-dasd-ipl.txt => s390-dasd-ipl.rst} | 65 ++++++++++--------- 3 files changed, 37 insertions(+), 31 deletions(-) rename docs/devel/{s390-dasd-ipl.txt => s390-dasd-ipl.rst} (77%) diff --git a/MAINTAINERS b/MAINTAINERS index f6511d5120ce..628bf7454088 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1235,7 +1235,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 diff --git a/docs/devel/index.rst b/docs/devel/index.rst index ac862152dcb3..b084def854b8 100644 --- a/docs/devel/index.rst +++ b/docs/devel/index.rst @@ -24,3 +24,4 @@ Contents: tcg tcg-plugins bitops + s390-dasd-ipl diff --git a/docs/devel/s390-dasd-ipl.txt b/docs/devel/s390-dasd-ipl.rst similarity index 77% rename from docs/devel/s390-dasd-ipl.txt rename to docs/devel/s390-dasd-ipl.rst index 9107e048e4e6..1f6a7ea01ce6 100644 --- a/docs/devel/s390-dasd-ipl.txt +++ b/docs/devel/s390-dasd-ipl.rst @@ -1,25 +1,28 @@ -***************************** -***** s390 hardware IPL ***** -***************************** +Booting from real channel-attached devices on s390x +=================================================== + +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 - 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 + need to function. + + 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. -2. Execute channel program at 0x0. -3. LPSW 0x0. +1. Place a "Read IPL" ccw into memory location ``0x0`` with chaining bit on. +2. Execute channel program at ``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. -2. Execute "Read IPL" at 0x0. +1. Place "Read IPL" ccw into memory location ``0x0``, but turn off chaining bit. +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. -- 2.21.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation 2020-01-28 18:01 ` [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation Cornelia Huck @ 2020-02-05 11:02 ` Thomas Huth 2020-02-07 12:05 ` Peter Maydell 1 sibling, 0 replies; 12+ messages in thread From: Thomas Huth @ 2020-02-05 11:02 UTC (permalink / raw) To: Cornelia Huck, Tony Krowiak, Jason J . Herne Cc: Halil Pasic, Christian Borntraeger, qemu-s390x, qemu-devel, Pierre Morel On 28/01/2020 19.01, Cornelia Huck wrote: > While at it, also fix the numbering in 'What QEMU does'. > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > --- > MAINTAINERS | 2 +- > docs/devel/index.rst | 1 + > .../{s390-dasd-ipl.txt => s390-dasd-ipl.rst} | 65 ++++++++++--------- > 3 files changed, 37 insertions(+), 31 deletions(-) > rename docs/devel/{s390-dasd-ipl.txt => s390-dasd-ipl.rst} (77%) Looks sane to me. Reviewed-by: Thomas Huth <thuth@redhat.com> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation 2020-01-28 18:01 ` [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation Cornelia Huck 2020-02-05 11:02 ` Thomas Huth @ 2020-02-07 12:05 ` Peter Maydell 2020-02-07 15:22 ` Cornelia Huck 1 sibling, 1 reply; 12+ messages in thread From: Peter Maydell @ 2020-02-07 12:05 UTC (permalink / raw) To: Cornelia Huck Cc: Tony Krowiak, Jason J . Herne, Thomas Huth, Pierre Morel, QEMU Developers, Halil Pasic, Christian Borntraeger, qemu-s390x On Tue, 28 Jan 2020 at 19:36, Cornelia Huck <cohuck@redhat.com> wrote: > > While at it, also fix the numbering in 'What QEMU does'. > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > --- > diff --git a/docs/devel/s390-dasd-ipl.txt b/docs/devel/s390-dasd-ipl.rst > similarity index 77% > rename from docs/devel/s390-dasd-ipl.txt > rename to docs/devel/s390-dasd-ipl.rst > index 9107e048e4e6..1f6a7ea01ce6 100644 > --- a/docs/devel/s390-dasd-ipl.txt > +++ b/docs/devel/s390-dasd-ipl.rst > @@ -1,25 +1,28 @@ > -***************************** > -***** s390 hardware IPL ***** > -***************************** > +Booting from real channel-attached devices on s390x > +=================================================== > + > +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``. I think the indentation here is off -- rST likes to see every line in a multiline bullet point start in the same column, like this: 1. A READ IPL ccw is constructed in memory location ``0x0``. This ccw, by ... at cylinder... Otherwise I think you end up with a blockquote by accident. Formatting-wise the rest looks OK to me (and the other enumerated lists in this document don't have this odd indentation, just this first set of 1..4). thanks -- PMM ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation 2020-02-07 12:05 ` Peter Maydell @ 2020-02-07 15:22 ` Cornelia Huck 0 siblings, 0 replies; 12+ messages in thread From: Cornelia Huck @ 2020-02-07 15:22 UTC (permalink / raw) To: Peter Maydell Cc: Tony Krowiak, Jason J . Herne, Thomas Huth, Pierre Morel, QEMU Developers, Halil Pasic, Christian Borntraeger, qemu-s390x On Fri, 7 Feb 2020 12:05:09 +0000 Peter Maydell <peter.maydell@linaro.org> wrote: > On Tue, 28 Jan 2020 at 19:36, Cornelia Huck <cohuck@redhat.com> wrote: > > > > While at it, also fix the numbering in 'What QEMU does'. > > > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > > --- > > > diff --git a/docs/devel/s390-dasd-ipl.txt b/docs/devel/s390-dasd-ipl.rst > > similarity index 77% > > rename from docs/devel/s390-dasd-ipl.txt > > rename to docs/devel/s390-dasd-ipl.rst > > index 9107e048e4e6..1f6a7ea01ce6 100644 > > --- a/docs/devel/s390-dasd-ipl.txt > > +++ b/docs/devel/s390-dasd-ipl.rst > > @@ -1,25 +1,28 @@ > > -***************************** > > -***** s390 hardware IPL ***** > > -***************************** > > +Booting from real channel-attached devices on s390x > > +=================================================== > > + > > +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``. > > I think the indentation here is off -- rST likes to see every line > in a multiline bullet point start in the same column, like this: > > 1. A READ IPL ccw is constructed in memory location ``0x0``. > This ccw, by ... > at cylinder... > > Otherwise I think you end up with a blockquote by accident. Hm, the resulting html looked sane to me... but making this consistent is a good idea anyway. > > Formatting-wise the rest looks OK to me (and the other enumerated > lists in this document don't have this odd indentation, just this > first set of 1..4). Thanks for looking! > > thanks > -- PMM > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH RFC 2/2] docs: rstfy vfio-ap documentation 2020-01-28 18:01 [PATCH RFC 0/2] docs: rstfy some s390 docs Cornelia Huck 2020-01-28 18:01 ` [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation Cornelia Huck @ 2020-01-28 18:01 ` Cornelia Huck 2020-02-05 11:05 ` Thomas Huth ` (2 more replies) 2020-02-05 10:51 ` [PATCH RFC 0/2] docs: rstfy some s390 docs Cornelia Huck 2 siblings, 3 replies; 12+ messages in thread From: Cornelia Huck @ 2020-01-28 18:01 UTC (permalink / raw) To: Tony Krowiak, Jason J . Herne Cc: Thomas Huth, Pierre Morel, Cornelia Huck, qemu-devel, Halil Pasic, Christian Borntraeger, qemu-s390x Move to system/, as this is mostly about configuring vfio-ap. Signed-off-by: Cornelia Huck <cohuck@redhat.com> --- MAINTAINERS | 2 +- docs/system/index.rst | 1 + docs/{vfio-ap.txt => system/vfio-ap.rst} | 755 ++++++++++++----------- 3 files changed, 387 insertions(+), 371 deletions(-) rename docs/{vfio-ap.txt => system/vfio-ap.rst} (56%) diff --git a/MAINTAINERS b/MAINTAINERS index 628bf7454088..0df0d07a7f97 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1545,7 +1545,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 diff --git a/docs/system/index.rst b/docs/system/index.rst index f66e6ea585cd..1a4b2c82acef 100644 --- a/docs/system/index.rst +++ b/docs/system/index.rst @@ -15,3 +15,4 @@ Contents: :maxdepth: 2 qemu-block-drivers + vfio-ap diff --git a/docs/vfio-ap.txt b/docs/system/vfio-ap.rst similarity index 56% rename from docs/vfio-ap.txt rename to docs/system/vfio-ap.rst index b1eb2deeaf2f..c8c5728e0aaa 100644 --- a/docs/vfio-ap.txt +++ b/docs/system/vfio-ap.rst @@ -1,17 +1,17 @@ Adjunct Processor (AP) Device ============================= -Contents: -========= -* 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: -============ +Contents +-------- +* `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 +21,8 @@ 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 +75,7 @@ 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,246 +114,254 @@ 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: - ------------------------------ - Guest1: adapters 1,2 domains 5,6 - Guest2: adapter 1,2 domain 7 +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). +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). - Example 2: Valid configuration: - ------------------------------ - Guest1: adapters 1,2 domains 5,6 - Guest2: adapters 3,4 domains 5,6 +Example 2: Valid configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Guest1: adapters 1,2 domains 5,6 +Guest2: adapters 3,4 domains 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) +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: adapters 1,2 domains 5,6 - Guest2: adapter 1 domains 6,7 +Example 3: Invalid configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Guest1: adapters 1,2 domains 5,6 +Guest2: adapter 1 domains 6,7 - This is an invalid configuration because both guests have access to - APQN (1,6). +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] -...... xx.yyyy -...... ... -...... cardxx -...... ... + /sys/bus/ap + ... [devices] + ...... xx.yyyy + ...... ... + ...... cardxx + ...... ... Where: - cardxx is AP adapter number xx (in hex) -....xx.yyyy is an APQN with xx specifying the APID and yyyy specifying the - APQI + +cardxx + 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: - -/sys/bus/ap -... [devices] -...... 05.0004 -...... 05.0047 -...... 05.00ab -...... 05.00ff -...... 06.0004 -...... 06.0047 -...... 06.00ab -...... 06.00ff -...... card05 -...... card06 +host system would look like this:: + + /sys/bus/ap + ... [devices] + ...... 05.0004 + ...... 05.0047 + ...... 05.00ab + ...... 05.00ff + ...... 06.0004 + ...... 06.0047 + ...... 06.00ab + ...... 06.00ff + ...... card05 + ...... 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: - -/sys/bus/ap -... [drivers] -...... [cex2acard] for Crypto Express 2/3 accelerator cards -...... [cex2aqueue] for AP queues served by Crypto Express 2/3 - accelerator cards -...... [cex4card] for Crypto Express 4/5/6 accelerator and coprocessor - cards -...... [cex4queue] for AP queues served by Crypto Express 4/5/6 - accelerator and coprocessor cards -...... [pcixcccard] for Crypto Express 2/3 coprocessor cards -...... [pcixccqueue] for AP queues served by Crypto Express 2/3 - coprocessor cards +device that can be assigned to the LPAR on which a linux host is running:: + + /sys/bus/ap + ... [drivers] + ...... [cex2acard] for Crypto Express 2/3 accelerator cards + ...... [cex2aqueue] for AP queues served by Crypto Express 2/3 + accelerator cards + ...... [cex4card] for Crypto Express 4/5/6 accelerator and coprocessor + cards + ...... [cex4queue] for AP queues served by Crypto Express 4/5/6 + accelerator and coprocessor cards + ...... [pcixcccard] for Crypto Express 2/3 coprocessor cards + ...... [pcixccqueue] for AP queues served by Crypto Express 2/3 + 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 - (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 '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 - (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. +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 - It indicates: +It indicates: 1, 2, 3, 4, 5, and 7-255 belong to the default drivers' pool, and 0 and 6 belong to the vfio_ap device driver's pool. - The APQN of each AP queue device assigned to the linux host is checked by the - AP bus against the set of APQNs derived from the cross product of APIDs - and APQIs marked as usable only by the default AP queue device drivers. If a - match is detected, only the default AP queue device drivers will be probed; - otherwise, the vfio_ap device driver will be probed. +The APQN of each AP queue device assigned to the linux host is checked by the +AP bus against the set of APQNs derived from the cross product of APIDs +and APQIs marked as usable only by the default AP queue device drivers. If a +match is detected, only the default AP queue device drivers will be probed; +otherwise, the vfio_ap device driver will be probed. - By default, the two masks are set to reserve all APQNs for use by the default - AP queue device drivers. There are two ways the default masks can be changed: +By default, the two masks are set to reserve all APQNs for use by the default +AP queue device drivers. There are two ways the default masks can be changed: - 1. The sysfs mask files can be edited by echoing a string into the - respective sysfs mask file in one of two formats: + 1. The sysfs mask files can be edited by echoing a string into the + respective sysfs mask file in one of two formats: - * 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: + * 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:: 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). + 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). - If the string is longer than the mask, the operation is terminated with - an error (EINVAL). + 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 - the corresponding bit is to be switched on ('+') or off ('-'). Some - valid values are: + * 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 + the corresponding bit is to be switched on ('+') or off ('-'). Some + 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 - Switches bits 6 and 240 (0xf0) off + Switches bits 0 and 71 (0x47) on + Switches bits 6 and 240 (0xf0) off - Note that the bits not specified in the list remain as they were before - the operation. + Note that the bits not specified in the list remain as they were before + the operation. - 2. The masks can also be changed at boot time via parameters on the kernel - command line like this: + 2. The masks can also be changed at boot time via parameters on the kernel + command line like this:: ap.apmask=0xffff ap.aqmask=0x40 - This would create the following masks: + 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 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] -......[matrix] -......... [mdev_supported_types] -............ [vfio_ap-passthrough] -............... create -............... [devices] + /sys/devices + ... [vfio_ap] + ......[matrix] + ......... [mdev_supported_types] + ............ [vfio_ap-passthrough] + ............... create + ............... [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 +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] -......[matrix] -......... [mdev_supported_types] -............ [vfio_ap-passthrough] -............... create -............... [devices] -.................. [$uuid] + /sys/devices + ... [vfio_ap] + ......[matrix] + ......... [mdev_supported_types] + ............ [vfio_ap-passthrough] + ............... create + ............... [devices] + .................. [$uuid] 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: - -/sys/devices -... [vfio_ap] -......[matrix] -......... [mdev_supported_types] -............ [vfio_ap-passthrough] -............... create -............... [devices] -.................. [$uuid] -..................... assign_adapter -..................... assign_control_domain -..................... assign_domain -..................... matrix -..................... unassign_adapter -..................... unassign_control_domain -..................... unassign_domain +KVM guest:: + + /sys/devices + ... [vfio_ap] + ......[matrix] + ......... [mdev_supported_types] + ............ [vfio_ap-passthrough] + ............... create + ............... [devices] + .................. [$uuid] + ..................... assign_adapter + ..................... assign_control_domain + ..................... assign_domain + ..................... matrix + ..................... unassign_adapter + ..................... unassign_control_domain + ..................... unassign_domain 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 @@ -379,16 +387,16 @@ assign_adapter operation will terminate with an error (EADDRINUSE). 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 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 @@ -415,16 +423,16 @@ assign_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 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 @@ -437,31 +445,31 @@ assign_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 -/sys/bus/mdev/drivers/vfio_mdev/$uuid -/sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough/devices/$uuid + /sys/devices/vfio_ap/matrix/$uuid + /sys/bus/mdev/devices/$uuid + /sys/bus/mdev/drivers/vfio_mdev/$uuid + /sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough/devices/$uuid 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,20 +494,22 @@ 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: + Where: - $model is the CPU model defined for the guest (defaults to the model of - the host system if not specified). + $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 - (off). The default for CPU models zEC12 or newer - is ap=on. AP facilities must be installed on the guest if a - vfio-ap device (-device vfio-ap,sysfsdev=$path) is configured - for the guest, or the guest will fail to start. + 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 + 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,27 +517,29 @@ 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: + 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 - not (off). The default for CPU models zEC12 or newer - is apqci=on; for older models, QCI will not be installed. + 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. - If QCI is installed (apqci=on) but AP facilities are not - (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. + If QCI is installed (``apqci=on``) but AP facilities are not + (``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. - If the QCI facility is not installed, APQNs with an APQI - greater than 15 will not be detected by the AP bus - running on the guest. + If the QCI facility is not installed, APQNs with an APQI + greater than 15 will not be detected by the AP bus + running on the guest. 3. Adjunct Process Facility Test (APFT) facility @@ -535,48 +547,50 @@ 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: + Where: - $model is the CPU model defined for the guest (defaults to the model of - the host system if not specified). + $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 - not (off). The default for CPU models zEC12 and - newer is apft=on for older models, APFT will not be - installed. + 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 + installed. - If APFT is installed (apft=on) but AP facilities are not - (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. + If APFT is installed (``apft=on``) but AP facilities are not + (``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. - It also makes no sense to turn APFT off because the AP bus - running on the guest will not detect CEX4 and newer devices - without it. Since only CEX4 and newer devices are supported - for guest usage, no AP devices can be made accessible to a - guest started without APFT installed. + It also makes no sense to turn APFT off because the AP bus + running on the guest will not detect CEX4 and newer devices + without it. Since only CEX4 and newer devices are supported + 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 - device to which AP resources to be used by the guest have been assigned. +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,66 +601,67 @@ 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 - device was attached to the virtual machine's ap-bus. +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 ------- -CARD.DOMAIN TYPE MODE ------------------------------- -05 CEX5C CCA-Coproc -05.0004 CEX5C CCA-Coproc -05.00ab CEX5C CCA-Coproc -06 CEX5A Accelerator -06.0004 CEX5A Accelerator -06.00ab CEX5C CCA-Coproc - -Guest2 ------- -CARD.DOMAIN TYPE MODE ------------------------------- -05 CEX5A Accelerator -05.0047 CEX5A Accelerator -05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171), - -Guest3 ------- -CARD.DOMAIN TYPE MODE ------------------------------- -06 CEX5A Accelerator -06.0047 CEX5A Accelerator -06.00ff CEX5A Accelerator +look like this:: + + Guest1 + ------ + CARD.DOMAIN TYPE MODE + ------------------------------ + 05 CEX5C CCA-Coproc + 05.0004 CEX5C CCA-Coproc + 05.00ab CEX5C CCA-Coproc + 06 CEX5A Accelerator + 06.0004 CEX5A Accelerator + 06.00ab CEX5C CCA-Coproc + + Guest2 + ------ + CARD.DOMAIN TYPE MODE + ------------------------------ + 05 CEX5A Accelerator + 05.0047 CEX5A Accelerator + 05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171), + + Guest3 + ------ + CARD.DOMAIN TYPE MODE + ------------------------------ + 06 CEX5A Accelerator + 06.0047 CEX5A Accelerator + 06.00ff CEX5A Accelerator 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 +672,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,21 +682,21 @@ These are the steps: * VFIO_MDEV_DEVICE * KVM - If using make menuconfig select the following to build the vfio_ap module: - -> Device Drivers - -> IOMMU Hardware Support - select S390 AP IOMMU Support - -> VFIO Non-Privileged userspace driver framework - -> Mediated device driver framework - -> VFIO driver for Mediated devices - -> I/O subsystem - -> VFIO support for AP devices + If using make menuconfig select the following to build the vfio_ap module:: + -> Device Drivers + -> IOMMU Hardware Support + select S390 AP IOMMU Support + -> VFIO Non-Privileged userspace driver framework + -> Mediated device driver framework + -> VFIO driver for Mediated devices + -> I/O subsystem + -> VFIO support for AP devices 2. Secure the AP queues to be used by the three guests so that the host can not 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,19 +705,19 @@ 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: - - /sys/bus/ap - ... [drivers] - ...... [vfio_ap] - ......... [05.0004] - ......... [05.0047] - ......... [05.00ab] - ......... [05.00ff] - ......... [06.0004] - ......... [06.0047] - ......... [06.00ab] - ......... [06.00ff] + to the AP queue devices bound to it:: + + /sys/bus/ap + ... [drivers] + ...... [vfio_ap] + ......... [05.0004] + ......... [05.0047] + ......... [05.00ab] + ......... [05.00ff] + ......... [06.0004] + ......... [06.0047] + ......... [06.00ab] + ......... [06.00ff] Keep in mind that only type 10 and newer adapters (i.e., CEX4 and later) can be bound to the vfio_ap device driver. The reason for this is to @@ -712,153 +728,152 @@ 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 + cat /sys/bus/ap/devices/card05/hwtype The hwtype must be 10 or higher (CEX4 or newer) in order to be bound to the vfio_ap device driver. 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] - ------ [vfio_ap-passthrough] (passthrough mediated matrix device type) - --------- create - --------- [devices] + /sys/devices/vfio_ap/matrix/ + ... [mdev_supported_types] + ...... [vfio_ap-passthrough] (passthrough mediated matrix device type) + ......... create + ......... [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 - or + or - echo $uuid1 > create - echo $uuid2 > create - echo $uuid3 > create + :: + + 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: - - /sys/devices/vfio_ap/matrix/ - --- [mdev_supported_types] - ------ [vfio_ap-passthrough] - --------- [devices] - ------------ [$uuid1] - --------------- assign_adapter - --------------- assign_control_domain - --------------- assign_domain - --------------- matrix - --------------- unassign_adapter - --------------- unassign_control_domain - --------------- unassign_domain - - ------------ [$uuid2] - --------------- assign_adapter - --------------- assign_control_domain - --------------- assign_domain - --------------- matrix - --------------- unassign_adapter - ----------------unassign_control_domain - ----------------unassign_domain - - ------------ [$uuid3] - --------------- assign_adapter - --------------- assign_control_domain - --------------- assign_domain - --------------- matrix - --------------- unassign_adapter - ----------------unassign_control_domain - ----------------unassign_domain + $uuid2 and $uuid3 and this is the sysfs directory structure after creation:: + + /sys/devices/vfio_ap/matrix/ + ... [mdev_supported_types] + ...... [vfio_ap-passthrough] + ......... [devices] + ............ [$uuid1] + ............... assign_adapter + ............... assign_control_domain + ............... assign_domain + ............... matrix + ............... unassign_adapter + ............... unassign_control_domain + ............... unassign_domain + + ............ [$uuid2] + ............... assign_adapter + ............... assign_control_domain + ............... assign_domain + ............... matrix + ............... unassign_adapter + ............... unassign_control_domain + ............... unassign_domain + + ............ [$uuid3] + ............... assign_adapter + ............... assign_control_domain + ............... assign_domain + ............... matrix + ............... unassign_adapter + ............... unassign_control_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 echo 4 > assign_domain echo 0xab > assign_domain - Control domains can similarly be assigned using the assign_control_domain - sysfs file. + Control domains can similarly be assigned using the assign_control_domain + 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 - 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 + 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 adapter number and yyyy is the domain number. The output for Guest1 - will look like this: + 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:: 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 \ - -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ... + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on -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 \ - -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ... + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on -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 \ - -device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ... + /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on -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] - ------ [vfio_ap-passthrough] - --------- [devices] - ------------ [$uuid1] - --------------- remove + ... [mdev_supported_types] + ...... [vfio_ap-passthrough] + ......... [devices] + ............ [$uuid1] + ............... remove echo 1 > remove - This will remove all of the mdev matrix device's sysfs structures including - the mdev device itself. To recreate and reconfigure the mdev matrix device, - all of the steps starting with step 3 will have to be performed again. Note - that the remove will fail if a guest using the mdev is still running. +This will remove all of the mdev matrix device's sysfs structures including +the mdev device itself. To recreate and reconfigure the mdev matrix device, +all of the steps starting with step 3 will have to be performed again. Note +that the remove will fail if a guest using the mdev is still running. - It is not necessary to remove an mdev matrix device, but one may want to - remove it if no guest will use it during the remaining lifetime of the linux - host. If the mdev matrix device is removed, one may want to also reconfigure - the pool of adapters and queues reserved for use by the default drivers. +It is not necessary to remove an mdev matrix device, but one may want to +remove it if no guest will use it during the remaining lifetime of the linux +host. If the mdev matrix device is removed, one may want to also reconfigure +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 +882,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 - running guest' section above. + unplugged before migrating the guest (see `Hot unplug a vfio-ap device from a + running guest`_ section above.) -- 2.21.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 2/2] docs: rstfy vfio-ap documentation 2020-01-28 18:01 ` [PATCH RFC 2/2] docs: rstfy vfio-ap documentation Cornelia Huck @ 2020-02-05 11:05 ` Thomas Huth 2020-02-07 12:43 ` Peter Maydell 2020-02-12 15:41 ` Cornelia Huck 2 siblings, 0 replies; 12+ messages in thread From: Thomas Huth @ 2020-02-05 11:05 UTC (permalink / raw) To: Cornelia Huck, Tony Krowiak, Jason J . Herne Cc: Halil Pasic, Christian Borntraeger, qemu-s390x, qemu-devel, Pierre Morel On 28/01/2020 19.01, Cornelia Huck wrote: > Move to system/, as this is mostly about configuring vfio-ap. > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > --- > MAINTAINERS | 2 +- > docs/system/index.rst | 1 + > docs/{vfio-ap.txt => system/vfio-ap.rst} | 755 ++++++++++++----------- > 3 files changed, 387 insertions(+), 371 deletions(-) > rename docs/{vfio-ap.txt => system/vfio-ap.rst} (56%) I'm not an expert in all that RST markdown syntax, but I think it's a good idea to do this change, so FWIW: Acked-by: Thomas Huth <thuth@redhat.com> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 2/2] docs: rstfy vfio-ap documentation 2020-01-28 18:01 ` [PATCH RFC 2/2] docs: rstfy vfio-ap documentation Cornelia Huck 2020-02-05 11:05 ` Thomas Huth @ 2020-02-07 12:43 ` Peter Maydell 2020-02-07 15:32 ` Cornelia Huck 2020-02-12 15:41 ` Cornelia Huck 2 siblings, 1 reply; 12+ messages in thread From: Peter Maydell @ 2020-02-07 12:43 UTC (permalink / raw) To: Cornelia Huck Cc: Tony Krowiak, Jason J . Herne, Thomas Huth, Pierre Morel, QEMU Developers, Halil Pasic, Christian Borntraeger, qemu-s390x On Tue, 28 Jan 2020 at 19:39, Cornelia Huck <cohuck@redhat.com> wrote: > > Move to system/, as this is mostly about configuring vfio-ap. > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > diff --git a/docs/vfio-ap.txt b/docs/system/vfio-ap.rst > similarity index 56% > rename from docs/vfio-ap.txt > rename to docs/system/vfio-ap.rst > index b1eb2deeaf2f..c8c5728e0aaa 100644 > --- a/docs/vfio-ap.txt > +++ b/docs/system/vfio-ap.rst > @@ -1,17 +1,17 @@ > Adjunct Processor (AP) Device > ============================= > > -Contents: > -========= > -* 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: > -============ > +Contents > +-------- > +* `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`_ > + You don't need to manually write out a table of contents. You can just have one line .. contents:: and Sphinx will produce an autogenerated table of contents (including a 'Contents' title) for you. https://docutils.sourceforge.io/docs/ref/rst/directives.html#table-of-contents An example where we already use this is docs/interop/live-block-operations.rst: https://www.qemu.org/docs/master/interop/live-block-operations.html > +Introduction > +------------ rST doesn't require it, but I'd recommend a blank line below the ---- line; I think it makes the source more readable. > 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 +21,8 @@ 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 +75,7 @@ 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,246 +114,254 @@ 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: > - ------------------------------ > - Guest1: adapters 1,2 domains 5,6 > - Guest2: adapter 1,2 domain 7 > +Example 1: Valid configuration > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +Guest1: adapters 1,2 domains 5,6 > +Guest2: adapter 1,2 domain 7 These don't render correctly -- rST thinks the "Example 1..." line is a subsection heading because of the underlining, and then renders the next two lines as runon-text: "Guest1: adapters 1,2 domains 5,6 Guest2: adapter 1,2 domain 7" Depending on what you want, you could try one of: * use a literal block (which gets you fixed-width font, preserved whitespace and linebreaks) * use a bulleted list * use one of rST's table formats (is it deliberate that line 1 is "adapters" and line 2 is "adapter" ?) > - 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). > +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). > > - Example 2: Valid configuration: > - ------------------------------ > - Guest1: adapters 1,2 domains 5,6 > - Guest2: adapters 3,4 domains 5,6 > +Example 2: Valid configuration > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +Guest1: adapters 1,2 domains 5,6 > +Guest2: adapters 3,4 domains 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) > +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) This is differently rendered from the equivalent text in example 1, because of the indent -- rST treats the 2 indented lines as a block quote, and indents them in the output, but flows the text into one long line. I think personally I'd opt to render like this: 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) (ie a bulleted list); but anyway consistency between the examples would be good. > > - Example 3: Invalid configuration: > - -------------------------------- > - Guest1: adapters 1,2 domains 5,6 > - Guest2: adapter 1 domains 6,7 > +Example 3: Invalid configuration > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +Guest1: adapters 1,2 domains 5,6 > +Guest2: adapter 1 domains 6,7 > > - This is an invalid configuration because both guests have access to > - APQN (1,6). > +This is an invalid configuration because both guests have access to > +APQN (1,6). > - * 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 > - the corresponding bit is to be switched on ('+') or off ('-'). Some > - valid values are: > + * 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 > + the corresponding bit is to be switched on ('+') or off ('-'). Some > + valid values are:: > > "+0" switches bit 0 on > "-13" switches bit 13 off > "+0x41" switches bit 65 on > "-0xff" switches bit 255 off Maybe use a definition list here rather than a literal block? valid values are: ``+0`` switches bit 0 on ``-13`` switches bit 13 off etc. The literal block is fine if you think it looks better though. > > assign_adapter Since these are filenames, you can enclose them in `` `` and they'll render as fixed-width text, which I think makes them stand out a bit better in the HTML. I'm pretty sure this works even in the term part of a definition list. Not in this diff, but should the 'No APQN...' para in the assign_domain docs really be a 2nd para of the preceding bullet point rather than either its own bullet point or a paragraph outside the bulleted list ? (ditto for assign_domain) > @@ -486,20 +494,22 @@ 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: > + Where: > > - $model is the CPU model defined for the guest (defaults to the model of > - the host system if not specified). > + $model Formatting $model and ap=on|off with `` `` would look nicer I think (ditto below) thanks -- PMM ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 2/2] docs: rstfy vfio-ap documentation 2020-02-07 12:43 ` Peter Maydell @ 2020-02-07 15:32 ` Cornelia Huck 2020-02-12 14:57 ` Cornelia Huck 0 siblings, 1 reply; 12+ messages in thread From: Cornelia Huck @ 2020-02-07 15:32 UTC (permalink / raw) To: Peter Maydell, Tony Krowiak Cc: Jason J . Herne, Thomas Huth, Pierre Morel, QEMU Developers, Halil Pasic, Christian Borntraeger, qemu-s390x On Fri, 7 Feb 2020 12:43:03 +0000 Peter Maydell <peter.maydell@linaro.org> wrote: > On Tue, 28 Jan 2020 at 19:39, Cornelia Huck <cohuck@redhat.com> wrote: > > > > Move to system/, as this is mostly about configuring vfio-ap. > > > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > > > diff --git a/docs/vfio-ap.txt b/docs/system/vfio-ap.rst > > similarity index 56% > > rename from docs/vfio-ap.txt > > rename to docs/system/vfio-ap.rst > > index b1eb2deeaf2f..c8c5728e0aaa 100644 > > --- a/docs/vfio-ap.txt > > +++ b/docs/system/vfio-ap.rst > > @@ -1,17 +1,17 @@ > > Adjunct Processor (AP) Device > > ============================= > > > > -Contents: > > -========= > > -* 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: > > -============ > > +Contents > > +-------- > > +* `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`_ > > + > > You don't need to manually write out a table of contents. You > can just have one line > > .. contents:: > > and Sphinx will produce an autogenerated table of contents > (including a 'Contents' title) for you. > > https://docutils.sourceforge.io/docs/ref/rst/directives.html#table-of-contents > > An example where we already use this is > docs/interop/live-block-operations.rst: > https://www.qemu.org/docs/master/interop/live-block-operations.html Oh, nice, will do. (Not sure how useful this was in the text document, anyway.) > > > > +Introduction > > +------------ > > rST doesn't require it, but I'd recommend a blank line below > the ---- line; I think it makes the source more readable. > > > 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 +21,8 @@ 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 +75,7 @@ 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,246 +114,254 @@ 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: > > - ------------------------------ > > - Guest1: adapters 1,2 domains 5,6 > > - Guest2: adapter 1,2 domain 7 > > +Example 1: Valid configuration > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > +Guest1: adapters 1,2 domains 5,6 > > +Guest2: adapter 1,2 domain 7 > > These don't render correctly -- rST thinks the "Example 1..." line > is a subsection heading because of the underlining, and then renders > the next two lines as runon-text: > "Guest1: adapters 1,2 domains 5,6 Guest2: adapter 1,2 domain 7" > > Depending on what you want, you could try one of: > * use a literal block (which gets you fixed-width font, preserved > whitespace and linebreaks) > * use a bulleted list > * use one of rST's table formats Hm... I think this is supposed to be: - header ("Example 1: ...") - config - explanation why this is a valid config Maybe a table? Tony, any preferences? > > (is it deliberate that line 1 is "adapters" and line 2 is "adapter" ?) I don't think so. > > > - 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). > > +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). > > > > - Example 2: Valid configuration: > > - ------------------------------ > > - Guest1: adapters 1,2 domains 5,6 > > - Guest2: adapters 3,4 domains 5,6 > > +Example 2: Valid configuration > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > +Guest1: adapters 1,2 domains 5,6 > > +Guest2: adapters 3,4 domains 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) > > +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) > > This is differently rendered from the equivalent text in example 1, > because of the indent -- rST treats the 2 indented lines as a block > quote, and indents them in the output, but flows the text into > one long line. > > I think personally I'd opt to render like this: > > 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) > > (ie a bulleted list); but anyway consistency between the examples > would be good. Nod. The indentation in the document was a bit inconsistent, it just did not matter before. > > > > > - Example 3: Invalid configuration: > > - -------------------------------- > > - Guest1: adapters 1,2 domains 5,6 > > - Guest2: adapter 1 domains 6,7 > > +Example 3: Invalid configuration > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > +Guest1: adapters 1,2 domains 5,6 > > +Guest2: adapter 1 domains 6,7 > > > > - This is an invalid configuration because both guests have access to > > - APQN (1,6). > > +This is an invalid configuration because both guests have access to > > +APQN (1,6). > > > - * 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 > > - the corresponding bit is to be switched on ('+') or off ('-'). Some > > - valid values are: > > + * 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 > > + the corresponding bit is to be switched on ('+') or off ('-'). Some > > + valid values are:: > > > > "+0" switches bit 0 on > > "-13" switches bit 13 off > > "+0x41" switches bit 65 on > > "-0xff" switches bit 255 off > > Maybe use a definition list here rather than a literal block? > > valid values are: > > ``+0`` > switches bit 0 on > ``-13`` > switches bit 13 off > > etc. The literal block is fine if you think it looks better though. Not sure if a definition list for something that is basically a list of examples makes sense. Will check how it renders. > > > > > > assign_adapter > > Since these are filenames, you can enclose them in `` `` and they'll > render as fixed-width text, which I think makes them stand out a > bit better in the HTML. I'm pretty sure this works even in the > term part of a definition list. That's probably a good idea, will check. > > Not in this diff, but should the 'No APQN...' para in the assign_domain > docs really be a 2nd para of the preceding bullet point rather than either > its own bullet point or a paragraph outside the bulleted list ? Will also check, I mostly converted this document via a whack-a-mole approach. > > (ditto for assign_domain) > > > > @@ -486,20 +494,22 @@ 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: > > + Where: > > > > - $model is the CPU model defined for the guest (defaults to the model of > > - the host system if not specified). > > + $model > > Formatting $model and ap=on|off with `` `` would look nicer I think > (ditto below) Yep, I'll check if there is anything else that should be fixed-width. > > thanks > -- PMM > Thanks for looking! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 2/2] docs: rstfy vfio-ap documentation 2020-02-07 15:32 ` Cornelia Huck @ 2020-02-12 14:57 ` Cornelia Huck 0 siblings, 0 replies; 12+ messages in thread From: Cornelia Huck @ 2020-02-12 14:57 UTC (permalink / raw) To: Peter Maydell, Tony Krowiak Cc: Jason J . Herne, Thomas Huth, Pierre Morel, QEMU Developers, Halil Pasic, Christian Borntraeger, qemu-s390x On Fri, 7 Feb 2020 16:32:18 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > On Fri, 7 Feb 2020 12:43:03 +0000 > Peter Maydell <peter.maydell@linaro.org> wrote: > > > On Tue, 28 Jan 2020 at 19:39, Cornelia Huck <cohuck@redhat.com> wrote: > > > > > > Move to system/, as this is mostly about configuring vfio-ap. > > > > > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > > > - Example 1: Valid configuration: > > > - ------------------------------ > > > - Guest1: adapters 1,2 domains 5,6 > > > - Guest2: adapter 1,2 domain 7 > > > +Example 1: Valid configuration > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > +Guest1: adapters 1,2 domains 5,6 > > > +Guest2: adapter 1,2 domain 7 > > > > These don't render correctly -- rST thinks the "Example 1..." line > > is a subsection heading because of the underlining, and then renders > > the next two lines as runon-text: > > "Guest1: adapters 1,2 domains 5,6 Guest2: adapter 1,2 domain 7" > > > > Depending on what you want, you could try one of: > > * use a literal block (which gets you fixed-width font, preserved > > whitespace and linebreaks) > > * use a bulleted list > > * use one of rST's table formats > > Hm... I think this is supposed to be: > - header ("Example 1: ...") > - config > - explanation why this is a valid config > > Maybe a table? Tony, any preferences? > > > > > (is it deliberate that line 1 is "adapters" and line 2 is "adapter" ?) > > I don't think so. > > > > > > - 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). > > > +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). This section now looks like this: Example 1: Valid configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +----------+--------+--------+ | | Guest1 | Guest2 | +==========+========+========+ | adapters | 1, 2 | 1, 2 | +----------+--------+--------+ | domains | 5, 6 | 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). Seems more readable to me, also in the rendered html. (Not sure if switching rows/columns would be better.) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 2/2] docs: rstfy vfio-ap documentation 2020-01-28 18:01 ` [PATCH RFC 2/2] docs: rstfy vfio-ap documentation Cornelia Huck 2020-02-05 11:05 ` Thomas Huth 2020-02-07 12:43 ` Peter Maydell @ 2020-02-12 15:41 ` Cornelia Huck 2 siblings, 0 replies; 12+ messages in thread From: Cornelia Huck @ 2020-02-12 15:41 UTC (permalink / raw) To: Tony Krowiak, Jason J . Herne Cc: Thomas Huth, Pierre Morel, qemu-devel, Halil Pasic, Christian Borntraeger, qemu-s390x On Tue, 28 Jan 2020 19:01:42 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > Move to system/, as this is mostly about configuring vfio-ap. > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > --- > MAINTAINERS | 2 +- > docs/system/index.rst | 1 + > docs/{vfio-ap.txt => system/vfio-ap.rst} | 755 ++++++++++++----------- > 3 files changed, 387 insertions(+), 371 deletions(-) > rename docs/{vfio-ap.txt => system/vfio-ap.rst} (56%) > > -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 > ------- > -CARD.DOMAIN TYPE MODE > ------------------------------- > -05 CEX5C CCA-Coproc > -05.0004 CEX5C CCA-Coproc > -05.00ab CEX5C CCA-Coproc > -06 CEX5A Accelerator > -06.0004 CEX5A Accelerator > -06.00ab CEX5C CCA-Coproc > - > -Guest2 > ------- > -CARD.DOMAIN TYPE MODE > ------------------------------- > -05 CEX5A Accelerator > -05.0047 CEX5A Accelerator > -05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171), > - > -Guest3 > ------- > -CARD.DOMAIN TYPE MODE > ------------------------------- > -06 CEX5A Accelerator > -06.0047 CEX5A Accelerator > -06.00ff CEX5A Accelerator > +look like this:: > + > + Guest1 > + ------ > + CARD.DOMAIN TYPE MODE > + ------------------------------ > + 05 CEX5C CCA-Coproc > + 05.0004 CEX5C CCA-Coproc > + 05.00ab CEX5C CCA-Coproc > + 06 CEX5A Accelerator > + 06.0004 CEX5A Accelerator > + 06.00ab CEX5C CCA-Coproc > + > + Guest2 > + ------ > + CARD.DOMAIN TYPE MODE > + ------------------------------ > + 05 CEX5A Accelerator > + 05.0047 CEX5A Accelerator > + 05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171), Just noticed this trailing stuff (had already been in the original file). Looks like a stray paste, will remove. > + > + Guest3 > + ------ > + CARD.DOMAIN TYPE MODE > + ------------------------------ > + 06 CEX5A Accelerator > + 06.0047 CEX5A Accelerator > + 06.00ff CEX5A Accelerator ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH RFC 0/2] docs: rstfy some s390 docs 2020-01-28 18:01 [PATCH RFC 0/2] docs: rstfy some s390 docs Cornelia Huck 2020-01-28 18:01 ` [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation Cornelia Huck 2020-01-28 18:01 ` [PATCH RFC 2/2] docs: rstfy vfio-ap documentation Cornelia Huck @ 2020-02-05 10:51 ` Cornelia Huck 2 siblings, 0 replies; 12+ messages in thread From: Cornelia Huck @ 2020-02-05 10:51 UTC (permalink / raw) To: Tony Krowiak, Jason J . Herne Cc: Thomas Huth, Pierre Morel, qemu-devel, Halil Pasic, Christian Borntraeger, qemu-s390x On Tue, 28 Jan 2020 19:01:40 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > https://qemu.readthedocs.io/en/latest/index.html collects various > documents from the QEMU docs/ subdirectory; however, none of the > s390 files are currently included. Therefore, I set out to convert > the existing files to rst and hook them up. > > s390-dasd-ipl was straightforward enough; I also found a numbering > issue. > > vfio-ap was quite a bit more involved, but I hope I have produced > something readable (would benefit from some more review). I also > moved this into the system/ subdirectory; not sure if that is the > best resting place, but it seemed to be the most reasonable one. > > Tested via running 'make html' and inspecting the output. > > Branch: https://github.com/cohuck/qemu rstfy-s390 > > Cornelia Huck (2): > docs: rstfy s390 dasd ipl documentation > docs: rstfy vfio-ap documentation > > MAINTAINERS | 4 +- > docs/devel/index.rst | 1 + > .../{s390-dasd-ipl.txt => s390-dasd-ipl.rst} | 65 +- > docs/system/index.rst | 1 + > docs/{vfio-ap.txt => system/vfio-ap.rst} | 755 +++++++++--------- > 5 files changed, 424 insertions(+), 402 deletions(-) > rename docs/devel/{s390-dasd-ipl.txt => s390-dasd-ipl.rst} (77%) > rename docs/{vfio-ap.txt => system/vfio-ap.rst} (56%) > Friendly ping. Anybody got some spare cycles to look at this? ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-02-12 15:43 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-01-28 18:01 [PATCH RFC 0/2] docs: rstfy some s390 docs Cornelia Huck 2020-01-28 18:01 ` [PATCH RFC 1/2] docs: rstfy s390 dasd ipl documentation Cornelia Huck 2020-02-05 11:02 ` Thomas Huth 2020-02-07 12:05 ` Peter Maydell 2020-02-07 15:22 ` Cornelia Huck 2020-01-28 18:01 ` [PATCH RFC 2/2] docs: rstfy vfio-ap documentation Cornelia Huck 2020-02-05 11:05 ` Thomas Huth 2020-02-07 12:43 ` Peter Maydell 2020-02-07 15:32 ` Cornelia Huck 2020-02-12 14:57 ` Cornelia Huck 2020-02-12 15:41 ` Cornelia Huck 2020-02-05 10:51 ` [PATCH RFC 0/2] docs: rstfy some s390 docs Cornelia Huck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).