From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"jean-philippe.brucker@arm.com" <jean-philippe.brucker@arm.com>,
"Tian, Jun J" <jun.j.tian@intel.com>,
"Sun, Yi Y" <yi.y.sun@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alex Williamson <alex.williamson@redhat.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Subject: Re: [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
Date: Thu, 6 Feb 2020 10:12:53 -0800 [thread overview]
Message-ID: <20200206101253.7fb43e07@jacob-builder> (raw)
In-Reply-To: <A2975661238FB949B60364EF0F2C25743A1993E8@SHSMSX104.ccr.corp.intel.com>
Hi Alex,
On Fri, 31 Jan 2020 12:41:06 +0000
"Liu, Yi L" <yi.l.liu@intel.com> wrote:
> > > +static int vfio_iommu_type1_pasid_free(struct vfio_iommu *iommu,
> > > + unsigned int pasid)
> > > +{
> > > + struct vfio_mm *vmm = iommu->vmm;
> > > + int ret = 0;
> > > +
> > > + mutex_lock(&iommu->lock);
> > > + if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)) {
> >
> > But we could have been IOMMU backed when the pasid was allocated,
> > did we just leak something? In fact, I didn't spot anything in
> > this series that handles a container with pasids allocated losing
> > iommu backing. I'd think we want to release all pasids when that
> > happens since permission for the user to hold pasids goes along
> > with having an iommu backed device.
>
> oh, yes. If a container lose iommu backend, then needs to reclaim the
> allocated PASIDs. right? I'll add it. :-)
>
> > Also, do we want _free() paths that can fail?
>
> I remember we discussed if a _free() path can fail, I think we agreed
> to let _free() path always success. :-)
Just to add some details. We introduced IOASID notifier such that when
VFIO frees a PASID, consumers such as IOMMU, can do the cleanup
therefore ensure free always succeeds.
https://www.spinics.net/lists/kernel/msg3349928.html
https://www.spinics.net/lists/kernel/msg3349930.html
This was not in my v9 set as I was considering some race conditions
w.r.t. registering notifier, gets notifications, and free call. I will
post it in v10.
Thanks,
Jacob
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: "Liu, Yi L" <yi.l.liu@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"Raj, Ashok" <ashok.raj@intel.com>,
"Tian, Jun J" <jun.j.tian@intel.com>,
"Sun, Yi Y" <yi.y.sun@intel.com>,
"jean-philippe.brucker@arm.com" <jean-philippe.brucker@arm.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
jacob.jun.pan@linux.intel.com
Subject: Re: [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
Date: Thu, 6 Feb 2020 10:12:53 -0800 [thread overview]
Message-ID: <20200206101253.7fb43e07@jacob-builder> (raw)
In-Reply-To: <A2975661238FB949B60364EF0F2C25743A1993E8@SHSMSX104.ccr.corp.intel.com>
Hi Alex,
On Fri, 31 Jan 2020 12:41:06 +0000
"Liu, Yi L" <yi.l.liu@intel.com> wrote:
> > > +static int vfio_iommu_type1_pasid_free(struct vfio_iommu *iommu,
> > > + unsigned int pasid)
> > > +{
> > > + struct vfio_mm *vmm = iommu->vmm;
> > > + int ret = 0;
> > > +
> > > + mutex_lock(&iommu->lock);
> > > + if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)) {
> >
> > But we could have been IOMMU backed when the pasid was allocated,
> > did we just leak something? In fact, I didn't spot anything in
> > this series that handles a container with pasids allocated losing
> > iommu backing. I'd think we want to release all pasids when that
> > happens since permission for the user to hold pasids goes along
> > with having an iommu backed device.
>
> oh, yes. If a container lose iommu backend, then needs to reclaim the
> allocated PASIDs. right? I'll add it. :-)
>
> > Also, do we want _free() paths that can fail?
>
> I remember we discussed if a _free() path can fail, I think we agreed
> to let _free() path always success. :-)
Just to add some details. We introduced IOASID notifier such that when
VFIO frees a PASID, consumers such as IOMMU, can do the cleanup
therefore ensure free always succeeds.
https://www.spinics.net/lists/kernel/msg3349928.html
https://www.spinics.net/lists/kernel/msg3349930.html
This was not in my v9 set as I was considering some race conditions
w.r.t. registering notifier, gets notifications, and free call. I will
post it in v10.
Thanks,
Jacob
next prev parent reply other threads:[~2020-02-06 18:07 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 12:11 [RFC v3 0/8] vfio: expose virtual Shared Virtual Addressing to VMs Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
2020-01-29 12:11 ` [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free) Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
2020-01-29 23:55 ` Alex Williamson
2020-01-29 23:55 ` Alex Williamson
2020-01-31 12:41 ` Liu, Yi L
2020-01-31 12:41 ` Liu, Yi L
2020-02-06 9:41 ` Liu, Yi L
2020-02-06 9:41 ` Liu, Yi L
2020-02-06 18:12 ` Jacob Pan [this message]
2020-02-06 18:12 ` Jacob Pan
2020-02-18 5:07 ` Liu, Yi L
2020-02-18 5:07 ` Liu, Yi L
2020-01-29 12:11 ` [RFC v3 2/8] vfio/type1: Make per-application (VM) PASID quota tunable Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
2020-01-29 23:56 ` Alex Williamson
2020-01-29 23:56 ` Alex Williamson
2020-02-05 6:23 ` Liu, Yi L
2020-02-05 6:23 ` Liu, Yi L
2020-02-07 19:43 ` Jacob Pan
2020-02-07 19:43 ` Jacob Pan
2020-02-08 8:46 ` Liu, Yi L
2020-02-08 8:46 ` Liu, Yi L
2020-01-29 12:11 ` [RFC v3 3/8] vfio: Reclaim PASIDs when application is down Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
2020-01-29 23:56 ` Alex Williamson
2020-01-29 23:56 ` Alex Williamson
2020-01-31 12:42 ` Liu, Yi L
2020-01-31 12:42 ` Liu, Yi L
2020-01-29 12:11 ` [RFC v3 4/8] vfio/type1: Add VFIO_NESTING_GET_IOMMU_UAPI_VERSION Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
2020-01-29 23:56 ` Alex Williamson
2020-01-29 23:56 ` Alex Williamson
2020-01-31 13:04 ` Liu, Yi L
2020-01-31 13:04 ` Liu, Yi L
2020-02-03 18:00 ` Alex Williamson
2020-02-03 18:00 ` Alex Williamson
2020-02-05 6:19 ` Liu, Yi L
2020-02-05 6:19 ` Liu, Yi L
2020-01-29 12:11 ` [RFC v3 5/8] vfio/type1: Report 1st-level/stage-1 page table format to userspace Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
2020-01-29 12:11 ` [RFC v3 6/8] vfio/type1: Bind guest page tables to host Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
2020-01-29 12:11 ` [RFC v3 7/8] vfio/type1: Add VFIO_IOMMU_CACHE_INVALIDATE Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
2020-01-29 12:11 ` [RFC v3 8/8] vfio/type1: Add vSVA support for IOMMU-backed mdevs Liu, Yi L
2020-01-29 12:11 ` Liu, Yi L
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=20200206101253.7fb43e07@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe.brucker@arm.com \
--cc=jun.j.tian@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@intel.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.