From: Alex Williamson <alex.williamson@redhat.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Matthew Rosato <mjrosato@linux.ibm.com>,
linux-s390@vger.kernel.org, cohuck@redhat.com,
schnelle@linux.ibm.com, farman@linux.ibm.com,
pmorel@linux.ibm.com, borntraeger@linux.ibm.com,
hca@linux.ibm.com, gor@linux.ibm.com,
gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
svens@linux.ibm.com, frankja@linux.ibm.com, david@redhat.com,
imbrenda@linux.ibm.com, vneethv@linux.ibm.com,
oberpar@linux.ibm.com, freude@linux.ibm.com, thuth@redhat.com,
pasic@linux.ibm.com, pbonzini@redhat.com, corbet@lwn.net,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v7 17/22] vfio-pci/zdev: add open/close device hooks
Date: Mon, 16 May 2022 13:38:39 -0600 [thread overview]
Message-ID: <20220516133839.7e116489.alex.williamson@redhat.com> (raw)
In-Reply-To: <20220516183558.GN1343366@nvidia.com>
On Mon, 16 May 2022 15:35:58 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Mon, May 16, 2022 at 02:30:46PM -0400, Matthew Rosato wrote:
>
> > Conceptually I think this would work for QEMU anyway (it always sets the kvm
> > before we open the device). I tried to test the idea quickly but couldn't
> > get the following to apply on vfio-next or your vfio_group_locking -- but I
> > understand what you're trying to do so I'll re-work and try it out.
>
> I created it on 8c9350e9bf43de1ebab3cc8a80703671e6495ab4 which is the
> vfio_group_locking.. I can send you a github if it helps
> https://github.com/jgunthorpe/linux/commits/vfio_group_lockin
>
> > @Alex can you think of any usecase/reason why we would need to be able to
> > set the KVM sometime after the device was opened? Doing something like
> > below would break that, as this introduces the assumption that the group is
> > associated with the KVM before the device is opened (and if it's not, the
> > device open fails).
>
> Keep in mind that GVT already hard requires this ordering to even
> allow open_device to work - so it already sets a floor for what
> userspace can do..
How is this going to work when vfio devices are exposed directly? We
currently have a strict ordering through the group to get to the
device, and it's therefore a reasonable requirement for userspace to
register the group with kvm before opening the device. Is the notifier
and async KVM registration necessary to support this dependency with
direct device access? I don't have as clear a picture of the ordering
with with direct access. Thanks,
Alex
next prev parent reply other threads:[~2022-05-16 19:40 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-13 19:14 [PATCH v7 00/22] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 01/22] s390/sclp: detect the zPCI load/store interpretation facility Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 02/22] s390/sclp: detect the AISII facility Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 03/22] s390/sclp: detect the AENI facility Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 04/22] s390/sclp: detect the AISI facility Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 05/22] s390/airq: pass more TPI info to airq handlers Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 06/22] s390/airq: allow for airq structure that uses an input vector Matthew Rosato
2022-05-16 10:18 ` Thomas Huth
2022-05-13 19:14 ` [PATCH v7 07/22] s390/pci: externalize the SIC operation controls and routine Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 08/22] s390/pci: stash associated GISA designation Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 09/22] s390/pci: stash dtsm and maxstbl Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 10/22] vfio/pci: introduce CONFIG_VFIO_PCI_ZDEV_KVM Matthew Rosato
2022-05-16 16:59 ` Jason Gunthorpe
2022-05-13 19:14 ` [PATCH v7 11/22] KVM: s390: pci: add basic kvm_zdev structure Matthew Rosato
2022-05-13 19:14 ` [PATCH v7 12/22] KVM: s390: pci: do initial setup for AEN interpretation Matthew Rosato
2022-05-13 19:15 ` [PATCH v7 13/22] KVM: s390: pci: enable host forwarding of Adapter Event Notifications Matthew Rosato
2022-05-13 19:15 ` [PATCH v7 14/22] KVM: s390: mechanism to enable guest zPCI Interpretation Matthew Rosato
2022-05-16 10:49 ` Thomas Huth
2022-05-13 19:15 ` [PATCH v7 15/22] KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding Matthew Rosato
2022-05-13 19:15 ` [PATCH v7 16/22] KVM: s390: pci: add routines to start/stop interpretive execution Matthew Rosato
2022-05-13 19:15 ` [PATCH v7 17/22] vfio-pci/zdev: add open/close device hooks Matthew Rosato
2022-05-16 17:27 ` Jason Gunthorpe
2022-05-16 18:30 ` Matthew Rosato
2022-05-16 18:35 ` Jason Gunthorpe
2022-05-16 19:38 ` Alex Williamson [this message]
2022-05-16 23:11 ` Jason Gunthorpe
2022-05-16 21:59 ` Matthew Rosato
2022-05-16 23:05 ` Jason Gunthorpe
2022-05-17 6:21 ` Christoph Hellwig
2022-05-17 12:01 ` Jason Gunthorpe
2022-05-13 19:15 ` [PATCH v7 18/22] vfio-pci/zdev: add function handle to clp base capability Matthew Rosato
2022-05-13 19:15 ` [PATCH v7 19/22] vfio-pci/zdev: different maxstbl for interpreted devices Matthew Rosato
2022-05-13 19:15 ` [PATCH v7 20/22] KVM: s390: add KVM_S390_ZPCI_OP to manage guest zPCI devices Matthew Rosato
2022-05-16 9:52 ` Thomas Huth
2022-05-16 15:35 ` Matthew Rosato
2022-05-16 16:37 ` Christian Borntraeger
2022-05-18 9:19 ` Thomas Huth
2022-05-13 19:15 ` [PATCH v7 21/22] KVM: s390: introduce CPU feature for zPCI Interpretation Matthew Rosato
2022-05-13 19:15 ` [PATCH v7 22/22] MAINTAINERS: additional files related kvm s390 pci passthrough Matthew Rosato
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=20220516133839.7e116489.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=jgg@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=thuth@redhat.com \
--cc=vneethv@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 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.