All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Tony Krowiak <akrowiak@linux.ibm.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Tony Krowiak <akrowiak@linux.vnet.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, freude@de.ibm.com, schwidefsky@de.ibm.com,
	heiko.carstens@de.ibm.com, cohuck@redhat.com,
	kwankhede@nvidia.com, bjsdjshi@linux.vnet.ibm.com,
	pbonzini@redhat.com, pmorel@linux.vnet.ibm.com,
	alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com,
	jjherne@linux.vnet.ibm.com, thuth@redhat.com,
	pasic@linux.vnet.ibm.com, berrange@redhat.com,
	fiuczy@linux.vnet.ibm.com, buendgen@de.ibm.com,
	frankja@linux.ibm.com
Subject: Re: [PATCH v11 26/26] s390: doc: detailed specifications for AP virtualization
Date: Fri, 28 Sep 2018 13:42:13 +0200	[thread overview]
Message-ID: <2c045dc8-6b73-6b9d-5d1a-c256ca20685b@de.ibm.com> (raw)
In-Reply-To: <a9b69a08-e415-4f76-d36c-73fc2a354f9e@linux.ibm.com>



On 09/27/2018 09:19 PM, Tony Krowiak wrote:

> The following fixup attempts to clarify the bit ordering confusion,
> hopefully this is acceptable.
> 

looks good to me, I will fold in.

> -----------------------------------8<-----------------------------------
> 
> From: Tony Krowiak <akrowiak@linux.ibm.com>
> Date: Thu, 27 Sep 2018 14:51:12 -0400
> Subject: [FIXUP v10] fixup! s390: doc: detailed specifications for AP
>  virtualization
> 
> Better explains mask bit ordering.
> 
> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
> ---
>  Documentation/s390/vfio-ap.txt | 127 +++++++++++++++++++++++----------
>  1 file changed, 91 insertions(+), 36 deletions(-)
> 
> diff --git a/Documentation/s390/vfio-ap.txt b/Documentation/s390/vfio-ap.txt
> index bec67eb7141c..599eb0f75c07 100644
> --- a/Documentation/s390/vfio-ap.txt
> +++ b/Documentation/s390/vfio-ap.txt
> @@ -123,21 +123,24 @@ to identify the adapters, usage domains and control domains assigned to the KVM
>  guest:
> 
>  * The AP Mask (APM) field is a bit mask that identifies the AP adapters assigned
> -  to the KVM guest. Each bit in the mask, from most significant to least
> -  significant bit, corresponds to an APID from 0-255. If a bit is set, the
> -  corresponding adapter is valid for use by the KVM guest.
> +  to the KVM guest. 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 corresponding adapter is valid for
> +  use by the KVM guest.
> 
>  * The AP Queue Mask (AQM) field is a bit mask identifying the AP usage domains
> -  assigned to the KVM guest. Each bit in the mask, from most significant to
> -  least significant bit, corresponds to an AP queue index (APQI) from 0-255. If
> -  a bit is set, the corresponding queue is valid for use by the KVM guest.
> +  assigned to the KVM guest. 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 AP queue index (APQI) from 0-255. If a bit is set, the corresponding queue
> +  is valid for use by the KVM guest.
> 
>  * The AP Domain Mask field is a bit mask that identifies the AP control domains
>    assigned to the KVM guest. The ADM bit mask controls which domains can be
>    changed by an AP command-request message sent to a usage domain from the
> -  guest. Each bit in the mask, from least significant to most significant bit,
> -  corresponds to a domain from 0-255. If a bit is set, the corresponding domain
> -  can be modified by an AP command-request message sent to a usage domain.
> +  guest. Each bit in the mask, from left to right (i.e. from most significant to
> +  least significant bit in big endian order), corresponds to a domain from
> +  0-255. If a bit is set, the corresponding domain can be modified by an AP
> +  command-request message sent to a usage domain.
> 
>  If you recall from the description of an AP Queue, AP instructions include
>  an APQN to identify the AP queue to which an AP command-request message is to be
> @@ -503,23 +506,34 @@ These are the steps:
>     access them. To secure them, 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 vfio_ap device driver'. The sysfs files containing
> -   the sysfs locations of the masks are:
> +   available for use by the vfio_ap device driver'. The location of the sysfs
> +   files containing 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 most significant to least significant bit,
> -   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.
> +   (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 most significant to least significant bit,
> -   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.
> +   (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:
> +
> +      0x7dffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> +
> +    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
> @@ -530,38 +544,79 @@ These are the steps:
>     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 masks can be changed at boot time with the kernel command line
> -      like this:
> +   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:
> +
> + 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).
> +
> +        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:
> +
> +           "+0"    switches bit 0 on
> +           "-13"   switches bit 13 off
> +           "+0x41" switches bit 65 on
> +           "-0xff" switches bit 255 off
> +
> +           The following example:
> +              +0,-6,+0x47,-0xf0
> +
> +              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.
> +
> +   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 give these two pools:
> +         This would create the following masks:
> 
> -            default drivers pool:    adapter 0-15, domain 1
> -            alternate drivers pool:  adapter 16-255, domains 2-255
> +            apmask:
> + 0xffff000000000000000000000000000000000000000000000000000000000000
> 
> -   2. The sysfs mask files can also be edited by echoing a string into the
> -      respective file in one of two formats:
> +            aqmask:
> + 0x4000000000000000000000000000000000000000000000000000000000000000
> 
> -      * 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. If the string is longer than the mask, the
> -        operation is terminated with an error (EINVAL).
> +         Resulting in these two pools:
> 
> -      * A plus ('+') or minus ('-') followed by a numerical value. Valid
> -        examples are "+1", "-13", "+0x41", "-0xff" and even "+0" and "-0". Only
> -        the corresponding bit in the mask is switched on ('+') or off ('-'). The
> -        values may also be specified in a comma-separated list to switch more
> -        than one bit on or off.
> +            default drivers pool:    adapter 0-15, domain 1
> +            alternate drivers pool:  adapter 16-255, domains 0, 2-255
> 
> +   Securing the APQNs for our example:
> +   ----------------------------------
>     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 masks as follows:
> +   APQNs can either be removed from the default masks:
> 
>        echo -5,-6 > /sys/bus/ap/apmask
> 
>        echo -4,-0x47,-0xab,-0xff > /sys/bus/ap/aqmask
> 
> +   Or the masks can be set as follows:
> +
> +      echo 0xf9ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \
> +      > apmask
> +
> +      echo 0xf7fffffffffffffffeffffffffffffffffffffffffeffffffffffffffffffffe \
> +      > aqmask
> +
>     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


  parent reply	other threads:[~2018-09-28 11:42 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 23:16 [PATCH v11 00/26] guest dedicated crypto adapters Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 01/26] KVM: s390: vsie: simulate VCPU SIE entry/exit Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 02/26] KVM: s390: introduce and use KVM_REQ_VSIE_RESTART Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 03/26] KVM: s390: refactor crypto initialization Tony Krowiak
2018-09-26 13:07   ` Cornelia Huck
2018-09-25 23:16 ` [PATCH v11 04/26] s390: vfio-ap: base implementation of VFIO AP device driver Tony Krowiak
2018-09-26  7:19   ` David Hildenbrand
2018-09-26  7:19     ` David Hildenbrand
2018-09-26 13:10   ` Cornelia Huck
2018-09-25 23:16 ` [PATCH v11 05/26] s390: vfio-ap: register matrix device with VFIO mdev framework Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 06/26] s390: vfio-ap: sysfs interfaces to configure adapters Tony Krowiak
2018-09-26 13:19   ` Cornelia Huck
2018-09-25 23:16 ` [PATCH v11 07/26] s390: vfio-ap: sysfs interfaces to configure domains Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 08/26] s390: vfio-ap: sysfs interfaces to configure control domains Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 09/26] s390: vfio-ap: sysfs interface to view matrix mdev matrix Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 10/26] KVM: s390: interfaces to clear CRYCB masks Tony Krowiak
2018-09-26 13:21   ` Cornelia Huck
2018-09-25 23:16 ` [PATCH v11 11/26] s390: vfio-ap: implement mediated device open callback Tony Krowiak
2018-09-28 10:14   ` Cornelia Huck
2018-09-28 13:02     ` Tony Krowiak
2018-09-28 13:33     ` [FIXUP v11] fixup! " Tony Krowiak
2018-09-28 13:34       ` Christian Borntraeger
2018-09-28 13:35       ` Cornelia Huck
2018-09-28 13:41         ` Halil Pasic
2018-09-28 13:42           ` Christian Borntraeger
2018-09-28 13:46             ` Cornelia Huck
2018-09-28 13:41         ` Christian Borntraeger
2018-09-25 23:16 ` [PATCH v11 12/26] s390: vfio-ap: implement VFIO_DEVICE_GET_INFO ioctl Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 13/26] s390: vfio-ap: zeroize the AP queues Tony Krowiak
2018-09-26 13:38   ` Cornelia Huck
2018-09-26 18:58     ` Christian Borntraeger
2018-09-27  7:04       ` Cornelia Huck
2018-09-25 23:16 ` [PATCH v11 14/26] s390: vfio-ap: implement VFIO_DEVICE_RESET ioctl Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 15/26] KVM: s390: Clear Crypto Control Block when using vSIE Tony Krowiak
2018-09-26  7:16   ` David Hildenbrand
2018-09-25 23:16 ` [PATCH v11 16/26] KVM: s390: vsie: Do the CRYCB validation first Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 17/26] KVM: s390: vsie: Make use of CRYCB FORMAT2 clear Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 18/26] KVM: s390: vsie: Allow CRYCB FORMAT-2 Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 19/26] KVM: s390: vsie: allow CRYCB FORMAT-1 Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 20/26] KVM: s390: vsie: allow CRYCB FORMAT-0 Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 21/26] KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-1 Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 22/26] KVM: s390: vsie: allow guest FORMAT-1 CRYCB on host FORMAT-2 Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 23/26] KVM: s390: vsie: allow guest FORMAT-0 " Tony Krowiak
2018-09-25 23:16 ` [PATCH v11 24/26] KVM: s390: device attrs to enable/disable AP interpretation Tony Krowiak
2018-09-26  7:14   ` David Hildenbrand
2018-09-26 13:44   ` Cornelia Huck
2018-09-25 23:16 ` [PATCH v11 25/26] KVM: s390: CPU model support for AP virtualization Tony Krowiak
2018-09-26  7:15   ` David Hildenbrand
2018-09-26  7:28     ` Christian Borntraeger
2018-09-26 13:39   ` Cornelia Huck
2018-09-25 23:16 ` [PATCH v11 26/26] s390: doc: detailed specifications " Tony Krowiak
2018-09-26 22:42   ` Alex Williamson
2018-09-27  6:53     ` Harald Freudenberger
2018-09-27 11:29     ` Halil Pasic
2018-09-27 11:51       ` Cornelia Huck
2018-09-27 11:59         ` Christian Borntraeger
2018-09-27 13:12           ` Tony Krowiak
2018-09-27 13:56       ` Tony Krowiak
2018-09-27 14:21     ` Tony Krowiak
2018-09-27 19:19     ` Tony Krowiak
2018-09-28  7:20       ` Christian Borntraeger
2018-09-28 11:42       ` Christian Borntraeger [this message]
2018-09-28 13:43     ` [FIXUP v9] fixup! fixup! " Tony Krowiak
2018-09-28 13:45       ` Christian Borntraeger
2018-09-26 12:30 ` [PATCH v11 00/26] guest dedicated crypto adapters Christian Borntraeger
2018-09-28 10:16 ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c045dc8-6b73-6b9d-5d1a-c256ca20685b@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=akrowiak@linux.vnet.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=alifm@linux.vnet.ibm.com \
    --cc=berrange@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=buendgen@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=fiuczy@linux.vnet.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=freude@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jjherne@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.vnet.ibm.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=pmorel@linux.vnet.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.