From: Tony Krowiak <akrowiak@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: pmorel@linux.ibm.com, borntraeger@de.ibm.com,
alex.williamson@redhat.com, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org, kvm@vger.kernel.org,
frankja@linux.ibm.com, pasic@linux.ibm.com, david@redhat.com,
schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
freude@linux.ibm.com, mimu@linux.ibm.com
Subject: Re: [PATCH v3 1/9] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
Date: Tue, 19 Feb 2019 17:27:05 -0500 [thread overview]
Message-ID: <f95dec76-ba2e-38b2-64f3-9abe4ca6a501@linux.ibm.com> (raw)
In-Reply-To: <20190218175747.53212f95.cohuck@redhat.com>
On 2/18/19 11:57 AM, Cornelia Huck wrote:
> On Mon, 18 Feb 2019 11:35:45 -0500
> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>
>> On 2/18/19 7:01 AM, Cornelia Huck wrote:
>>> On Fri, 15 Feb 2019 16:59:33 -0500
>>> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>>>
>>>> On 2/15/19 4:11 AM, Cornelia Huck wrote:
>>>>> On Thu, 14 Feb 2019 13:30:59 -0500
>>>>> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>>>>>
>>>>>> On 2/14/19 12:36 PM, Pierre Morel wrote:
>>>>>>> On 14/02/2019 17:57, Cornelia Huck wrote:
>>>
>>>>>>>> (And reading further in the current code, it seems we clear that
>>>>>>>> structure _after_ the matrix device had been setup, so how can that
>>>>>>>> even work? Where am I confused?)
>>>>>>>
>>>>>>> On device_register there were no bus, so the core just do not look for a
>>>>>>> driver and this field was nor tested nor overwritten.
>>>>>
>>>>> Hm... so has the callback in driver_for_each_device() in
>>>>> vfio_ap_verify_queue_reserved() ever been invoked at all? It seems this
>>>>> patch fixes more than just libudev issues...
>>>>
>>>> It is this patch that rendered the driver_for_each_device() in
>>>> vfio_ap_verify_queue_reserved() erroneous. That function gets called
>>>> every time an adapter or domain is assigned to the mdev. This patch
>>>> introduced the problem with driver_for_each_device().
>>>
>>> So, does this function need to be removed or called from another place,
>>> then? (It looks like it was dead code before.)
>>
>> I don't see why you think it's dead code:
>>
>> assign_adapter_store
>> ==> vfio_ap_mdev_verify_queues_reserved_for_apid
>> ==> vfio_ap_verify_queue_reserved
>> ==> driver_for_each_device
>>
>> The only way that the vfio_ap_verify_queue_reserved - the function that
>> calls driver_for_each_device - does not get called is if no bits have
>> yet been set in matrix_mdev->matrix.aqm.
>
> What I don't see is how this can be called if no device has been, in
> fact, bound to the driver in the driver core...
Let's start with the fact that one can create an mdev device regardless
of whether a queue has been bound to the vfio_ap driver. Once an mdev
device is created, one can start assigning adapters, domains and control
domains to it. Let's say the admin now attempts to assign an adapter, in
which case the assign_adapter_store() function is invoked. After
verifying that the APID passed in is a valid adapter number, the
vfio_ap_mdev_verify_queues_reserved_for_apid() function is called.
This function first checks if any domains have been assigned and if not,
calls vfio_ap_verify_queue_reserved(&apid, NULL). It is in this function
that the driver_for_each_device() function is called. Since there are
no devices bound to the vfio_ap device driver, the callback passed in to
the driver_for_each_device() function will never get called, so the
vfio_ap_mdev_verify_queues_reserved_for_apid() function will return
-EADDRNOTAVAIL. A similar flow will occur if the first assignment is for
a domain. The bottom line is, the driver_for_each_device() function is
called every time an adapter or domain is assigned.
>
next prev parent reply other threads:[~2019-02-19 22:27 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 13:51 [PATCH v3 0/9] [RFC] vfio: ap: ioctl definitions for AP Queue Interrupt Control Pierre Morel
2019-02-14 13:51 ` [PATCH v3 1/9] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem Pierre Morel
2019-02-14 14:54 ` Cornelia Huck
2019-02-14 15:05 ` Christian Borntraeger
2019-02-14 15:40 ` Cornelia Huck
2019-02-14 17:12 ` Tony Krowiak
2019-02-14 17:35 ` Pierre Morel
2019-02-14 15:47 ` Pierre Morel
2019-02-14 16:57 ` Cornelia Huck
2019-02-14 17:36 ` Pierre Morel
2019-02-14 18:30 ` Tony Krowiak
2019-02-15 9:11 ` Cornelia Huck
2019-02-15 21:59 ` Tony Krowiak
2019-02-18 12:01 ` Cornelia Huck
2019-02-18 16:35 ` Tony Krowiak
2019-02-18 16:57 ` Cornelia Huck
2019-02-19 22:27 ` Tony Krowiak [this message]
2019-02-20 9:05 ` Cornelia Huck
2019-02-14 15:01 ` Christian Borntraeger
2019-02-14 15:09 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 2/9] s390: ap: kvm: setting a hook for PQAP instructions Pierre Morel
2019-02-14 15:54 ` Cornelia Huck
2019-02-14 16:45 ` Pierre Morel
2019-02-15 9:26 ` Cornelia Huck
2019-02-15 9:55 ` Pierre Morel
2019-02-15 22:02 ` Tony Krowiak
2019-02-18 18:29 ` Pierre Morel
2019-02-18 22:42 ` Cornelia Huck
2019-02-19 19:50 ` Pierre Morel
2019-02-19 22:36 ` Tony Krowiak
2019-02-21 12:40 ` Pierre Morel
2019-02-19 22:50 ` Tony Krowiak
2019-02-14 13:51 ` [PATCH v3 3/9] s390: ap: new vfio_ap_queue structure Pierre Morel
2019-02-15 9:37 ` Cornelia Huck
2019-02-15 9:58 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 4/9] s390: ap: tools to find a queue with a specific APQN Pierre Morel
2019-02-15 9:49 ` Cornelia Huck
2019-02-15 10:10 ` Pierre Morel
2019-02-15 10:24 ` Cornelia Huck
2019-02-15 22:13 ` Tony Krowiak
2019-02-18 12:21 ` Cornelia Huck
2019-02-18 18:32 ` Pierre Morel
2019-02-22 15:04 ` Tony Krowiak
2019-02-14 13:51 ` [PATCH v3 5/9] s390: ap: tools to associate a queue to a matrix Pierre Morel
2019-02-15 22:30 ` Tony Krowiak
2019-02-18 18:36 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 6/9] vfio: ap: register IOMMU VFIO notifier Pierre Morel
2019-02-15 22:55 ` Tony Krowiak
2019-02-19 9:59 ` Halil Pasic
2019-02-19 19:04 ` Pierre Morel
2019-02-19 21:33 ` Tony Krowiak
2019-02-19 18:51 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 7/9] s390: ap: implement PAPQ AQIC interception in kernel Pierre Morel
2019-02-15 23:11 ` Tony Krowiak
2019-02-19 19:16 ` Pierre Morel
2019-02-20 11:54 ` Halil Pasic
2019-02-21 12:50 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 8/9] s390: ap: Cleanup on removing the AP device Pierre Morel
2019-02-15 23:29 ` Tony Krowiak
2019-02-19 19:29 ` Pierre Morel
2019-02-15 23:36 ` Tony Krowiak
2019-02-19 19:41 ` Pierre Morel
2019-02-14 13:51 ` [PATCH v3 9/9] s390: ap: kvm: add AP Queue Interruption Control facility Pierre Morel
2019-02-14 20:33 ` [PATCH v3 0/9] [RFC] vfio: ap: ioctl definitions for AP Queue Interrupt Control Tony Krowiak
2019-02-15 8:44 ` 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=f95dec76-ba2e-38b2-64f3-9abe4ca6a501@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=schwidefsky@de.ibm.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