public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Krowiak <akrowiak@linux.vnet.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>,
	pmorel@linux.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 v5 05/13] s390: vfio-ap: register matrix device with VFIO mdev framework
Date: Tue, 15 May 2018 12:11:22 -0400	[thread overview]
Message-ID: <9eabe7c2-4380-c57f-effe-e6d8e194466a@linux.vnet.ibm.com> (raw)
In-Reply-To: <1fb8d1ab-02d5-c170-08e8-a77526fbb7c4@linux.ibm.com>

On 05/15/2018 11:48 AM, Halil Pasic wrote:
>
>
> On 05/15/2018 05:16 PM, Tony Krowiak wrote:
>> On 05/15/2018 10:17 AM, Pierre Morel wrote:
>>> On 14/05/2018 21:42, Tony Krowiak wrote:
>>>> On 05/11/2018 01:18 PM, Halil Pasic wrote:
>>>>>
>>>>>
>>>>> On 05/07/2018 05:11 PM, Tony Krowiak wrote:
>>>>>> Registers the matrix device created by the VFIO AP device
>>>>>> driver with the VFIO mediated device framework.
>>>>>> Registering the matrix device will create the sysfs
>>>>>> structures needed to create mediated matrix devices
>>>>>> each of which will be used to configure the AP matrix
>>>>>> for a guest and connect it to the VFIO AP device driver.
>>>>>>
>>>>> [..]
>>>>>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
>>>>>> b/drivers/s390/crypto/vfio_ap_ops.c
>>>>>> new file mode 100644
>>>>>> index 0000000..d7d36fb
>>>>>> --- /dev/null
>>>>>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>>>>>> @@ -0,0 +1,106 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>> +/*
>>>>>> + * Adjunct processor matrix VFIO device driver callbacks.
>>>>>> + *
>>>>>> + * Copyright IBM Corp. 2017
>>>>>> + * Author(s): Tony Krowiak <akrowiak@linux.vnet.ibm.com>
>>>>>> + *
>>>>>> + */
>>>>>> +#include <linux/string.h>
>>>>>> +#include <linux/vfio.h>
>>>>>> +#include <linux/device.h>
>>>>>> +#include <linux/list.h>
>>>>>> +#include <linux/ctype.h>
>>>>>> +
>>>>>> +#include "vfio_ap_private.h"
>>>>>> +
>>>>>> +#define VFOP_AP_MDEV_TYPE_HWVIRT "passthrough"
>>>>>> +#define VFIO_AP_MDEV_NAME_HWVIRT "VFIO AP Passthrough Device"
>>>>>> +
>>>>>> +static int vfio_ap_mdev_create(struct kobject *kobj, struct 
>>>>>> mdev_device *mdev)
>>>>>> +{
>>>>>> +    struct ap_matrix *ap_matrix = 
>>>>>> to_ap_matrix(mdev_parent_dev(mdev));
>>>>>> +
>>>>>> +    ap_matrix->available_instances--;
>>>>>> +
>>>>>> +    return 0;
>>>>>> +}
>>>>>> +
>>>>>> +static int vfio_ap_mdev_remove(struct mdev_device *mdev)
>>>>>> +{
>>>>>> +    struct ap_matrix *ap_matrix = 
>>>>>> to_ap_matrix(mdev_parent_dev(mdev));
>>>>>> +
>>>>>> +    ap_matrix->available_instances++;
>>>>>> +
>>>>>> +    return 0;
>>>>>> +}
>>>>>> +
>>>>>
>>>>> The above functions seem to be called with the lock of this 
>>>>> auto-generated
>>>>> mdev parent device held. That's why we don't have to care about 
>>>>> synchronization
>>>>> ourselves, right?
>>>>
>>>> I would assume as much. The comments for the 'struct 
>>>> mdev_parent_ops' in
>>>> include/linux/mdev.h do not mention anything about synchronization, 
>>>> nor did I
>>>> see any locking or synchronization in the vfio_ccw implementation 
>>>> after which
>>>> I modeled my code, so frankly it is something I did not consider.
>>>>
>>>>>
>>>>>
>>>>> A small comment in the code could be helpful for mdev non-experts. 
>>>>> Hell, I would
>>>>> even consider documenting it for all mdev -- took me some time to 
>>>>> figure out.
>>>>
>>>> You may want to bring this up with the VFIO mdev maintainers, but 
>>>> I'd be happy to
>>>> include a comment in the functions in question if you think it 
>>>> important.
>>>>
>>>>>
>>>>>
>>>>> [..]
>>>>>
>>>>>
>>>>>> +int vfio_ap_mdev_register(struct ap_matrix *ap_matrix)
>>>>>> +{
>>>>>> +    int ret;
>>>>>> +
>>>>>> +    ret = mdev_register_device(&ap_matrix->device, 
>>>>>> &vfio_ap_matrix_ops);
>>>>>> +    if (ret)
>>>>>> +        return ret;
>>>>>> +
>>>>>> +    ap_matrix->available_instances = 
>>>>>> AP_MATRIX_MAX_AVAILABLE_INSTANCES;
>>>>>> +
>>>>>> +    return 0;
>>>>>> +}
>>>>>> +
>>>>>> +void vfio_ap_mdev_unregister(struct ap_matrix *ap_matrix)
>>>>>> +{
>>>>>> +    ap_matrix->available_instances--;
>>>>>
>>>>> What is this for? I don't understand.
>>>>
>>>> To control the number of mediated devices one can create for the 
>>>> matrix device.
>>>> Once the max is reached, the mdev framework will not allow creation 
>>>> of another
>>>> mediated device until one is removed. This counter keeps track of 
>>>> the number
>>>> of instances that can be created. This is documented with the mediated
>>>> framework. You may want to take a look at:
>>>>
>>>> Documentation/vfio-mediated-device.txt
>>>> Documentation/vfio.txt
>>>> Documentation/virtual/kvm/devices/vfio.txt
>>>
>>> This is what you do in create/remove.
>>> But here in unregister I agree with Halil, it does not seem to be 
>>> usefull.
>>
>> If that is in fact what Halil was asking, then I misinterpreted his 
>> question; I
>> thought he was asking what the available_instances was used for. You are
>> correct, this does not belong here although it makes little 
>> difference given
>> this is called only when the driver, which creates the matrix device, 
>> is unloaded.
>> It is necessary in the register function to initialize its value, but 
>> I'll
>> remove it from here.
>>
>
> I questioned the dubious usage of ap_matrix->available_instances 
> rather than
> asking what is the variable for.

I said I'd remove it.

>
>
> If I've had this deemed damaging I would have asked if it's damaging 
> in a way
> I think it is. For example take my comment on 'KVM: s390: interfaces 
> to manage
> guest's AP matrix'.

I apologize for not being able to read your mind. While this is not 
necessarily
necessary, it is not damaging because this is called only when the 
driver is being
unloaded. The point is moot, however, because I am removing it.

>
>
> Regards,
> Halil
>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Halil
>>>>>
>>>>>> + mdev_unregister_device(&ap_matrix->device);
>>>>>> +}
>>>>
>>>>
>>>
>>

  reply	other threads:[~2018-05-15 16:11 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-07 15:11 [PATCH v5 00/13] s390: vfio-ap: guest dedicated crypto adapters Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 01/13] KVM: s390: Interface to test whether APXA installed Tony Krowiak
2018-05-16 10:21   ` Cornelia Huck
2018-05-16 10:45     ` Tony Krowiak
2018-05-17  9:11       ` Harald Freudenberger
2018-05-17  9:44         ` Cornelia Huck
2018-05-07 15:11 ` [PATCH v5 02/13] KVM: s390: refactor crypto initialization Tony Krowiak
2018-05-16  8:51   ` Pierre Morel
2018-05-16 11:14     ` Tony Krowiak
2018-05-16 12:17       ` Pierre Morel
2018-05-16 12:21         ` Cornelia Huck
2018-05-07 15:11 ` [PATCH v5 03/13] KVM: s390: CPU model support for AP virtualization Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 04/13] s390: vfio-ap: base implementation of VFIO AP device driver Tony Krowiak
2018-05-16  8:21   ` Pierre Morel
2018-05-16 11:29     ` Tony Krowiak
2018-05-16 11:45     ` Tony Krowiak
2018-06-07  8:57   ` Pierre Morel
2018-06-13  7:41   ` Pierre Morel
2018-06-13  7:48     ` Cornelia Huck
2018-06-13 10:54       ` Pierre Morel
2018-06-13 11:14         ` Cornelia Huck
2018-06-13 12:01           ` Pierre Morel
2018-06-13 12:12             ` Cornelia Huck
2018-06-13 12:16               ` Pierre Morel
2018-06-14 13:04                 ` Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 05/13] s390: vfio-ap: register matrix device with VFIO mdev framework Tony Krowiak
2018-05-11 17:18   ` Halil Pasic
2018-05-14 19:42     ` Tony Krowiak
2018-05-15 14:17       ` Pierre Morel
2018-05-15 15:16         ` Tony Krowiak
2018-05-15 15:48           ` Halil Pasic
2018-05-15 16:11             ` Tony Krowiak [this message]
2018-05-17  7:44       ` Cornelia Huck
2018-05-21 15:13         ` Tony Krowiak
2018-05-22  8:19           ` Cornelia Huck
2018-05-22 21:41             ` Tony Krowiak
2018-05-16 10:42   ` Cornelia Huck
2018-05-16 12:48     ` Tony Krowiak
2018-05-16 12:58     ` Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP matrix Tony Krowiak
2018-05-11 16:08   ` Halil Pasic
2018-05-16 14:29     ` Tony Krowiak
2018-05-16 14:41       ` Pierre Morel
2018-05-21 15:23         ` Tony Krowiak
2018-05-15 14:55   ` Pierre Morel
2018-05-15 16:07     ` Tony Krowiak
2018-05-16  7:48       ` Pierre Morel
2018-05-16 13:12         ` Tony Krowiak
2018-05-16 13:15           ` Pierre Morel
2018-05-16 13:48             ` Tony Krowiak
2018-05-18  8:55               ` Pierre Morel
2018-05-23 14:29                 ` Tony Krowiak
2018-05-24  7:46                   ` Pierre Morel
2018-05-07 15:11 ` [PATCH v5 07/13] s390: vfio-ap: sysfs interfaces to configure adapters Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 08/13] s390: vfio-ap: sysfs interfaces to configure domains Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 09/13] s390: vfio-ap: sysfs interfaces to configure control domains Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 10/13] s390: vfio-ap: sysfs interface to view matrix mdev matrix Tony Krowiak
2018-05-16  7:55   ` Pierre Morel
2018-05-23 14:38     ` Tony Krowiak
2018-05-24  9:10       ` Pierre Morel
2018-05-30 14:28         ` Tony Krowiak
2018-06-05 12:40           ` Pierre Morel
2018-06-06 14:24             ` Tony Krowiak
2018-06-06 15:10               ` Pierre Morel
2018-06-07 12:53                 ` Tony Krowiak
2018-06-07 13:16                   ` Halil Pasic
2018-06-07 14:33                     ` Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 11/13] KVM: s390: implement mediated device open callback Tony Krowiak
2018-05-16  8:03   ` Pierre Morel
2018-05-23 14:45     ` Tony Krowiak
2018-05-24  9:08       ` Pierre Morel
2018-05-30 14:33         ` Tony Krowiak
2018-06-05 12:19           ` Pierre Morel
2018-06-06 14:28             ` Tony Krowiak
2018-06-06 16:08               ` Pierre Morel
2018-06-06 17:40                 ` Pierre Morel
2018-06-07 13:54                   ` Tony Krowiak
2018-06-07 15:20                     ` Pierre Morel
2018-06-07 16:30                       ` Tony Krowiak
2018-06-07 17:15                         ` Pierre Morel
2018-06-08 21:59                           ` Tony Krowiak
2018-06-11  9:23                             ` Pierre Morel
2018-06-11 11:32                               ` Halil Pasic
2018-06-11 11:49                                 ` Janosch Frank
2018-06-11 16:26                                   ` Tony Krowiak
2018-06-11 16:50                                     ` Halil Pasic
2018-06-11 16:54                                       ` Tony Krowiak
2018-06-11 12:50                                 ` Tony Krowiak
2018-06-11 12:56                               ` Tony Krowiak
2018-06-07 13:52                 ` Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 12/13] s390: vfio-ap: implement VFIO_DEVICE_GET_INFO ioctl Tony Krowiak
2018-05-07 15:11 ` [PATCH v5 13/13] s390: doc: detailed specifications for AP virtualization Tony Krowiak

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=9eabe7c2-4380-c57f-effe-e6d8e194466a@linux.vnet.ibm.com \
    --to=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.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