public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Krowiak <akrowiak@linux.ibm.com>
To: pmorel@linux.ibm.com, Tony Krowiak <akrowiak@linux.vnet.ibm.com>,
	linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Cc: freude@de.ibm.com, schwidefsky@de.ibm.com,
	heiko.carstens@de.ibm.com, borntraeger@de.ibm.com,
	cohuck@redhat.com, kwankhede@nvidia.com,
	bjsdjshi@linux.vnet.ibm.com, pbonzini@redhat.com,
	alex.williamson@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
Subject: Re: [PATCH v6 10/21] s390: vfio-ap: sysfs interfaces to configure adapters
Date: Fri, 13 Jul 2018 14:20:26 +0200	[thread overview]
Message-ID: <a58aee39-4ce4-7cf9-85f8-bc1eb440404c@linux.ibm.com> (raw)
In-Reply-To: <3ec78f60-e1b3-79fc-5592-c53520703bc7@linux.ibm.com>

On 07/09/2018 02:11 PM, Pierre Morel wrote:
> On 29/06/2018 23:11, Tony Krowiak wrote:
>> Provides the sysfs interfaces for assigning AP adapters to
>> and unassigning AP adapters from a mediated matrix device.
>>
>> The IDs of the AP adapters assigned to the mediated matrix
>> device are stored in an AP mask (APM). The bits in the APM,
>> from most significant to least significant bit, correspond to
>> AP adapter ID (APID) 0 to 255. When an adapter is assigned, the
>> bit corresponding the APID will be set in the APM.
>> Likewise, when an adapter is unassigned, the bit corresponding
>> to the APID will be cleared from the APM.
>>
>> The relevant sysfs structures are:
>>
>> /sys/devices/vfio_ap
>> ... [matrix]
>> ...... [mdev_supported_types]
>> ......... [vfio_ap-passthrough]
>> ............ [devices]
>> ...............[$uuid]
>> .................. assign_adapter
>> .................. unassign_adapter
>>
>> To assign an adapter to the $uuid mediated matrix device's APM,
>> write the APID to the assign_adapter file. To unassign an adapter,
>> write the APID to the unassign_adapter file. The APID is specified
>> using conventional semantics: If it begins with 0x the number will
>> be parsed as a hexadecimal number; if it begins with a 0 the number
>> will be parsed as an octal number; otherwise, it will be parsed as a
>> decimal number.
>>
>> For example, to assign adapter 173 (0xad) to the mediated matrix
>> device $uuid:
>>
>>     echo 173 > assign_adapter
>>
>>     or
>>
>>     echo 0xad > assign_adapter
>>
>>     or
>>
>>     echo 0255 > assign_adapter
>>
>> To unassign adapter 173 (0xad):
>>
>>     echo 173 > unassign_adapter
>>
>>     or
>>
>>     echo 0xad > unassign_adapter
>>
>>     or
>>
>>     echo 0255 > unassign_adapter
>>
>> The assignment will be rejected:
>>
>> * If the APID exceeds the maximum value for an AP adapter:
>>    * If the AP Extended Addressing (APXA) facility is
>>      installed, the max value is 255
>>    * Else the max value is 64
>>
>> * If no AP domains have yet been assigned and there are
>>    no AP queues bound to the VFIO AP driver that have an APQN
>>    with an APID matching that of the AP adapter being assigned.
>>
>> * If any of the APQNs that can be derived from the cross product
>>    of the APID being assigned and the AP queue index (APQI) of
>>    each of the AP domains previously assigned can not be matched
>>    with an APQN of an AP queue device reserved by the VFIO AP
>>    driver.
>>
>> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
>> ---
>>

snip [...]

>> +/**
>> + * assign_adapter_store
>> + *
>> + * @dev: the matrix device
>> + * @attr: a mediated matrix device attribute
>> + * @buf: a buffer containing the adapter ID (APID) to be assigned
>> + * @count: the number of bytes in @buf
>> + *
>> + * Parses the APID from @buf and assigns it to the mediated matrix 
>> device. The
>> + * APID must be a valid value:
>> + *    * The APID value must not exceed the maximum allowable AP 
>> adapter ID
>> + *
>> + *    * If there are no AP domains assigned, then there must be at 
>> least
>> + *      one AP queue device reserved by the VFIO AP device driver 
>> with an
>> + *      APQN containing @apid.
>
> I do not understand the reason here.
> Can you develop?

We forbid assignment of an adapter:

* If any APQNs that can be derived from the cross product of the input
   adapter number and the domain numbers already assigned are not bound
   to the VFIO AP driver.

* Or, if the APID of at least one APQN bound to the VFIO AP device driver
   does not match the input adapter number.

>
>
> I suppose that by reserved you mean bound. (then use bound)
> But I still can not understand the reason why.

Yes, I mean bound. The reason why is because we don't want to allow
a guest to use an AP queue that is not bound to the VFIO AP driver
because it will then be shared with the zcrypt driver and that
would be a breach of security. That may, however, not be what you
are really asking. Are you suggesting that we should allow assignment
of any APQN since this same check is done in the mdev open callback?

>
>
> Beside if I understand correctly what you do it forbid the automatic
> assignment of a new card plugged into the host.

Not necessarily; the same logic I described in my first answer above will
be applied if a new card is assigned.

>
>
>> + *
>> + *    * Else each APQN that can be derived from the intersection of 
>> @apid and
>> + *      the IDs of the AP domains already assigned must identify an 
>> AP queue
>> + *      that has been reserved by the VFIO AP device driver.
>> + *
>> + * Returns the number of bytes processed if the APID is valid; 
>> otherwise returns
>> + * an error.
>> + */
>> +static ssize_t assign_adapter_store(struct device *dev,
>> +                    struct device_attribute *attr,
>> +                    const char *buf, size_t count)
>> +{
>> +    int ret;
>> +    unsigned long apid;
>> +    struct mdev_device *mdev = mdev_from_dev(dev);
>> +    struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
>> +    unsigned long max_apid = matrix_mdev->matrix.apm_max;
>> +
>> +    ret = kstrtoul(buf, 0, &apid);
>> +    if (ret || (apid > max_apid)) {
>> +        pr_err("%s: %s: adapter id '%s' not a value from 0 to 
>> %02lu(%#04lx)",
>> +               VFIO_AP_MODULE_NAME, __func__, buf, max_apid, max_apid);
>> +
>> +        return ret ? ret : -EINVAL;
>> +    }
>> +
>> +    ret = vfio_ap_validate_apid(mdev, matrix_mdev, apid);
>> +    if (ret)
>> +        return ret;
>> +
>> +    /* Set the bit in the AP mask (APM) corresponding to the AP adapter
>> +     * number (APID). The bits in the mask, from most significant to 
>> least
>> +     * significant bit, correspond to APIDs 0-255.
>> +     */
>> +    set_bit_inv(apid, matrix_mdev->matrix.apm);
>> +
>> +    return count;
>> +}
>> +static DEVICE_ATTR_WO(assign_adapter);
>> +
>> +/**
>> + * unassign_adapter_store
>> + *
>> + * @dev: the matrix device
>> + * @attr: a mediated matrix device attribute
>> + * @buf: a buffer containing the adapter ID (APID) to be assigned
>> + * @count: the number of bytes in @buf
>> + *
>> + * Parses the APID from @buf and unassigns it from the mediated 
>> matrix device.
>> + * The APID must be a valid value
>> + *
>> + * Returns the number of bytes processed if the APID is valid; 
>> otherwise returns
>> + * an error.
>> + */
>> +static ssize_t unassign_adapter_store(struct device *dev,
>> +                      struct device_attribute *attr,
>> +                      const char *buf, size_t count)
>> +{
>> +    int ret;
>> +    unsigned long apid;
>> +    struct mdev_device *mdev = mdev_from_dev(dev);
>> +    struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
>> +    unsigned long max_apid = matrix_mdev->matrix.apm_max;
>> +
>> +    ret = kstrtoul(buf, 0, &apid);
>> +    if (ret || (apid > max_apid)) {
>> +        pr_err("%s: %s: adapter id '%s' must be a value from 0 to 
>> %02lu(%#04lx)",
>> +               VFIO_AP_MODULE_NAME, __func__, buf, max_apid, max_apid);
>> +
>> +        return ret ? ret : -EINVAL;
>> +    }
>> +
>> +    if (!test_bit_inv(apid, matrix_mdev->matrix.apm)) {
>> +        pr_err("%s: %s: adapter id %02lu(%#04lx) not assigned",
>> +               VFIO_AP_MODULE_NAME, __func__, apid, apid);
>> +
>> +        return -ENODEV;
>> +    }
>> +
>> +    clear_bit_inv((unsigned long)apid, matrix_mdev->matrix.apm);
>> +
>> +    return count;
>> +}
>> +DEVICE_ATTR_WO(unassign_adapter);
>> +
>> +static struct attribute *vfio_ap_mdev_attrs[] = {
>> +    &dev_attr_assign_adapter.attr,
>> +    &dev_attr_unassign_adapter.attr,
>> +    NULL
>> +};
>> +
>> +static struct attribute_group vfio_ap_mdev_attr_group = {
>> +    .attrs = vfio_ap_mdev_attrs
>> +};
>> +
>> +static const struct attribute_group *vfio_ap_mdev_attr_groups[] = {
>> +    &vfio_ap_mdev_attr_group,
>> +    NULL
>> +};
>> +
>>   static const struct mdev_parent_ops vfio_ap_matrix_ops = {
>>       .owner            = THIS_MODULE,
>>       .supported_type_groups    = vfio_ap_mdev_type_groups,
>> +    .mdev_attr_groups    = vfio_ap_mdev_attr_groups,
>>       .create            = vfio_ap_mdev_create,
>>       .remove            = vfio_ap_mdev_remove,
>>   };
>
>

  reply	other threads:[~2018-07-13 12:20 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29 21:11 [PATCH v6 00/21] s390: vfio-ap: guest dedicated crypto adapters Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 01/21] s390/zcrypt: Add ZAPQ inline function Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 02/21] s390/zcrypt: Review inline assembler constraints Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 03/21] s390/zcrypt: Show load of cards and queues in sysfs Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 04/21] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 05/21] KVM: s390: CPU model support for AP virtualization Tony Krowiak
2018-07-02 14:38   ` Christian Borntraeger
2018-07-02 15:37     ` Tony Krowiak
2018-07-02 15:41       ` Cornelia Huck
2018-07-02 15:54         ` Tony Krowiak
2018-07-02 16:11           ` Cornelia Huck
2018-07-02 16:20             ` Halil Pasic
2018-07-02 16:28               ` Cornelia Huck
2018-07-03 14:44                 ` Tony Krowiak
2018-07-02 16:04       ` Halil Pasic
2018-07-02 15:56   ` Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 06/21] KVM: s390: refactor crypto initialization Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 07/21] s390: vfio-ap: base implementation of VFIO AP device driver Tony Krowiak
2018-07-02 13:53   ` Halil Pasic
2018-07-02 15:39     ` Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 08/21] s390: vfio-ap: register matrix device with VFIO mdev framework Tony Krowiak
2018-07-09 14:17   ` Pierre Morel
2018-07-10  7:03     ` Harald Freudenberger
2018-07-12  7:32       ` Tony Krowiak
2018-07-09 15:44   ` Pierre Morel
2018-06-29 21:11 ` [PATCH v6 09/21] s390: vfio-ap: structure for storing mdev matrix Tony Krowiak
2018-07-06 14:26   ` Halil Pasic
2018-07-12 14:34     ` Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 10/21] s390: vfio-ap: sysfs interfaces to configure adapters Tony Krowiak
2018-07-09 12:11   ` Pierre Morel
2018-07-13 12:20     ` Tony Krowiak [this message]
2018-06-29 21:11 ` [PATCH v6 11/21] s390: vfio-ap: sysfs interfaces to configure domains Tony Krowiak
2018-07-09 12:13   ` Pierre Morel
2018-06-29 21:11 ` [PATCH v6 12/21] s390: vfio-ap: sysfs interfaces to configure control domains Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 13/21] s390: vfio-ap: sysfs interface to view matrix mdev matrix Tony Krowiak
2018-07-09 12:20   ` Pierre Morel
2018-07-09 14:38     ` Pierre Morel
2018-07-13 12:24       ` Tony Krowiak
2018-07-13 16:38         ` Halil Pasic
2018-06-29 21:11 ` [PATCH v6 14/21] s390: vfio-ap: implement mediated device open callback Tony Krowiak
2018-07-12 12:47   ` Halil Pasic
2018-07-12 16:03     ` Tony Krowiak
2018-07-13 10:48       ` Halil Pasic
2018-06-29 21:11 ` [PATCH v6 15/21] s390: vfio-ap: configure the guest's AP matrix Tony Krowiak
2018-07-11 23:22   ` Halil Pasic
2018-07-12 14:36     ` Tony Krowiak
2018-07-12 13:28   ` Halil Pasic
2018-07-12 14:37     ` Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 16/21] s390: vfio-ap: sysfs interface to view guest matrix Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 17/21] s390: vfio-ap: implement VFIO_DEVICE_GET_INFO ioctl Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 18/21] s390: vfio-ap: zeroize the AP queues Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 19/21] s390: vfio-ap: implement VFIO_DEVICE_RESET ioctl Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 20/21] KVM: s390: Handling of Cypto control block in VSIE Tony Krowiak
2018-06-29 21:11 ` [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization Tony Krowiak
2018-07-02 16:28   ` Halil Pasic
2018-07-03  7:46     ` Harald Freudenberger
2018-07-03  9:22       ` Halil Pasic
2018-07-03 11:52         ` Cornelia Huck
2018-07-03 12:20           ` Halil Pasic
2018-07-03 13:25             ` Cornelia Huck
2018-07-03 13:58               ` Halil Pasic
2018-07-03 14:30                 ` Cornelia Huck
2018-07-03 15:25                   ` Tony Krowiak
2018-07-03 16:14                   ` Halil Pasic
2018-07-03 15:20               ` Tony Krowiak
2018-07-03 15:17             ` Tony Krowiak
2018-07-03 15:00           ` Tony Krowiak
2018-07-03 14:56       ` Tony Krowiak
2018-07-04  8:31         ` Harald Freudenberger
2018-07-02 23:10   ` Halil Pasic
2018-07-03 16:36     ` Tony Krowiak
2018-07-04 16:31       ` Boris Fiuczynski
2018-07-05 13:29         ` Tony Krowiak
2018-07-09  9:21     ` Pierre Morel
2018-07-09 15:50       ` Halil Pasic
2018-07-10  8:49         ` Pierre Morel
2018-07-12  7:26       ` Tony Krowiak
2018-07-03  8:10   ` Harald Freudenberger
2018-07-09  9:02     ` Pierre Morel

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=a58aee39-4ce4-7cf9-85f8-bc1eb440404c@linux.ibm.com \
    --to=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=borntraeger@de.ibm.com \
    --cc=buendgen@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=fiuczy@linux.vnet.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.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox