From: Tony Krowiak <akrowiak@linux.ibm.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, jjherne@linux.ibm.com, freude@linux.ibm.com,
borntraeger@de.ibm.com, cohuck@redhat.com,
mjrosato@linux.ibm.com, alex.williamson@redhat.com,
kwankhede@nvidia.com, fiuczy@linux.ibm.com
Subject: Re: [PATCH v17 08/15] s390/vfio-ap: keep track of active guests
Date: Tue, 11 Jan 2022 16:27:37 -0500 [thread overview]
Message-ID: <25a5ee1a-b00f-bfcb-2273-8b5aa3927dcb@linux.ibm.com> (raw)
In-Reply-To: <20211230030419.2f3e5bda.pasic@linux.ibm.com>
On 12/29/21 21:04, Halil Pasic wrote:
> On Thu, 21 Oct 2021 11:23:25 -0400
> Tony Krowiak <akrowiak@linux.ibm.com> wrote:
>
>> The reason a lockdep splat can occur has to do with the fact that the
>> kvm->lock has to be taken before the vcpu->lock; so, for example, when a
>> secure execution guest is started, you may end up with the following
>> scenario:
>>
>> Interception of PQAP(AQIC) instruction executed on the guest:
>> ------------------------------------------------------------
>> handle_pqap: matrix_dev->lock
>> kvm_vcpu_ioctl: vcpu_mutex
>>
>> Start of secure execution guest:
>> -------------------------------
>> kvm_s390_cpus_to_pv: vcpu->mutex
>> kvm_arch_vm_ioctl: kvm->lock
>>
>> Queue is unbound from vfio_ap device driver:
>> -------------------------------------------
>> kvm->lock
>> vfio_ap_mdev_remove_queue: matrix_dev->lock
> The way you describe your scenario is a little ambiguous. It
> seems you choose a stack-trace like description, in a sense that for
> example for PQAP: first vcpu->mutex is taken and then matrix_dev->lock
> but you write the latter first and the former second. I think it is more
> usual to describe such stuff a a sequence of event in a sense that
> if A precedes B in the text (from the top towards the bottom), then
> execution of a A precedes the execution of B in time.
I wrote it the way it is displayed in the lockdep splat trace.
I'd be happy to re-arrange it if you'd prefer.
>
> Also you are inconsistent with vcpu_mutex vs vcpu->mutex.
>
> I can't say I understand the need for this yet. I have been starring
> at the end result for a while. Let me see if I can come up with an
> alternate proposal for some things.
Go for it, and may the force be with you.
>
> Regards,
> Halil
>
>
next prev parent reply other threads:[~2022-01-11 21:27 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 15:23 [PATCH v17 00/15] s390/vfio-ap: dynamic configuration support Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 01/15] s390/vfio-ap: Set pqap hook when vfio_ap module is loaded Tony Krowiak
2021-12-27 8:21 ` Halil Pasic
2022-01-11 21:13 ` Tony Krowiak
2022-01-04 16:22 ` Jason J. Herne
2022-01-11 17:29 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 02/15] s390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2021-12-27 8:25 ` Halil Pasic
2022-01-11 17:32 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 03/15] s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 04/15] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 05/15] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 06/15] s390/vfio-ap: refresh guest's APCB by filtering APQNs assigned to mdev Tony Krowiak
2021-12-27 8:53 ` Halil Pasic
2022-01-11 21:19 ` Tony Krowiak
2022-01-12 11:52 ` Halil Pasic
2022-01-15 0:31 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 07/15] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2021-12-27 9:06 ` Halil Pasic
2021-10-21 15:23 ` [PATCH v17 08/15] s390/vfio-ap: keep track of active guests Tony Krowiak
2021-12-30 2:04 ` Halil Pasic
2022-01-11 21:27 ` Tony Krowiak [this message]
2021-12-30 3:33 ` Halil Pasic
2022-01-11 21:58 ` Tony Krowiak
2022-01-11 22:19 ` Tony Krowiak
2022-01-12 14:25 ` Halil Pasic
2022-01-15 0:29 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 09/15] s390/vfio-ap: allow hot plug/unplug of AP resources using mdev device Tony Krowiak
2022-01-09 21:36 ` Halil Pasic
2022-01-11 22:42 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 10/15] s390/vfio-ap: reset queues after adapter/domain unassignment Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 11/15] s390/ap: driver callback to indicate resource in use Tony Krowiak
2021-11-04 11:27 ` Harald Freudenberger
2021-11-04 15:48 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 12/15] s390/vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 13/15] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 14/15] s390/ap: notify drivers on config changed and scan complete callbacks Tony Krowiak
2021-11-04 12:06 ` Harald Freudenberger
2021-11-04 15:50 ` Tony Krowiak
2021-11-05 8:23 ` Harald Freudenberger
2021-11-05 13:15 ` Harald Freudenberger
2021-11-08 14:27 ` Tony Krowiak
2021-11-08 14:26 ` Tony Krowiak
2022-02-04 10:43 ` Halil Pasic
2022-02-07 19:39 ` Tony Krowiak
2022-02-08 1:38 ` Halil Pasic
2022-02-08 3:27 ` Tony Krowiak
2021-10-21 15:23 ` [PATCH v17 15/15] s390/vfio-ap: update docs to include dynamic config support Tony Krowiak
2021-10-27 14:24 ` [PATCH v17 00/15] s390/vfio-ap: dynamic configuration support Tony Krowiak
2021-11-02 19:23 ` Tony Krowiak
2021-11-15 15:45 ` Tony Krowiak
2021-11-22 16:12 ` 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=25a5ee1a-b00f-bfcb-2273-8b5aa3927dcb@linux.ibm.com \
--to=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=fiuczy@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=jjherne@linux.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.ibm.com \
--cc=pasic@linux.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;
as well as URLs for NNTP newsgroup(s).