From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Liu, Yi L" <yi.l.liu@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.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@linaro.org" <jean-philippe@linaro.org>,
"peterx@redhat.com" <peterx@redhat.com>,
"Wu, Hao" <hao.wu@intel.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: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)
Date: Thu, 9 Jul 2020 11:05:13 -0700 [thread overview]
Message-ID: <20200709110513.3ff50f99@jacob-builder> (raw)
In-Reply-To: <20200709082751.320742ab@x1.home>
On Thu, 9 Jul 2020 08:27:51 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> > So I'm wondering can we fall back to prior proposal which only free
> > one PASID for a free request. how about your opinion?
>
> Doesn't it still seem like it would be a useful user interface to have
> a mechanism to free all pasids, by calling with exactly [0, MAX_UINT]?
> I'm not sure if there's another use case for this given than the user
> doesn't have strict control of the pasid values they get. Thanks,
Yes, I agree free all pasids of a guest is a useful interface. Since all
PASIDs under one VM is already tracked by an IOASID set with its XArray,
I don't see a need to track again in VFIO.
Shall we only free one & free all? IMHO, free range isn't that useful
and not really symmetric to PASID allocation in that allocation is one
at a time.
Can we just add a new flag, e.g. VFIO_IOMMU_FREE_ALL_PASID, and
ignored th range in free?
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "jean-philippe@linaro.org" <jean-philippe@linaro.org>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Sun, Yi Y" <yi.y.sun@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
"Tian, Jun J" <jun.j.tian@intel.com>
Subject: Re: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)
Date: Thu, 9 Jul 2020 11:05:13 -0700 [thread overview]
Message-ID: <20200709110513.3ff50f99@jacob-builder> (raw)
In-Reply-To: <20200709082751.320742ab@x1.home>
On Thu, 9 Jul 2020 08:27:51 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> > So I'm wondering can we fall back to prior proposal which only free
> > one PASID for a free request. how about your opinion?
>
> Doesn't it still seem like it would be a useful user interface to have
> a mechanism to free all pasids, by calling with exactly [0, MAX_UINT]?
> I'm not sure if there's another use case for this given than the user
> doesn't have strict control of the pasid values they get. Thanks,
Yes, I agree free all pasids of a guest is a useful interface. Since all
PASIDs under one VM is already tracked by an IOASID set with its XArray,
I don't see a need to track again in VFIO.
Shall we only free one & free all? IMHO, free range isn't that useful
and not really symmetric to PASID allocation in that allocation is one
at a time.
Can we just add a new flag, e.g. VFIO_IOMMU_FREE_ALL_PASID, and
ignored th range in free?
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-07-09 17:58 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-24 8:55 [PATCH v3 00/14] vfio: expose virtual Shared Virtual Addressing to VMs Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-06-24 8:55 ` [PATCH v3 01/14] vfio/type1: Refactor vfio_iommu_type1_ioctl() Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-07-02 21:21 ` Alex Williamson
2020-07-02 21:21 ` Alex Williamson
2020-07-03 3:46 ` Liu, Yi L
2020-07-03 3:46 ` Liu, Yi L
2020-06-24 8:55 ` [PATCH v3 02/14] iommu: Report domain nesting info Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-06-26 7:47 ` Jean-Philippe Brucker
2020-06-26 7:47 ` Jean-Philippe Brucker
2020-06-26 16:04 ` Robin Murphy
2020-06-26 16:04 ` Robin Murphy
2020-06-27 6:53 ` Liu, Yi L
2020-06-27 6:53 ` Liu, Yi L
2020-06-30 1:20 ` Tian, Kevin
2020-06-30 1:20 ` Tian, Kevin
2020-06-27 6:14 ` Liu, Yi L
2020-06-27 6:14 ` Liu, Yi L
2020-06-29 9:24 ` Stefan Hajnoczi
2020-06-29 9:24 ` Stefan Hajnoczi
2020-06-29 12:23 ` Liu, Yi L
2020-06-29 12:23 ` Liu, Yi L
2020-06-30 2:00 ` Tian, Kevin
2020-06-30 2:00 ` Tian, Kevin
2020-06-30 3:45 ` Liu, Yi L
2020-06-30 3:45 ` Liu, Yi L
2020-07-03 9:59 ` Stefan Hajnoczi
2020-07-03 9:59 ` Stefan Hajnoczi
2020-07-02 17:54 ` Alex Williamson
2020-07-02 17:54 ` Alex Williamson
2020-07-03 3:53 ` Liu, Yi L
2020-07-03 3:53 ` Liu, Yi L
2020-06-24 8:55 ` [PATCH v3 03/14] vfio/type1: Report iommu nesting info to userspace Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-07-02 18:38 ` Alex Williamson
2020-07-02 18:38 ` Alex Williamson
2020-07-03 6:05 ` Liu, Yi L
2020-07-03 6:05 ` Liu, Yi L
2020-07-03 13:03 ` Liu, Yi L
2020-07-03 13:03 ` Liu, Yi L
2020-06-24 8:55 ` [PATCH v3 04/14] vfio: Add PASID allocation/free support Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-07-02 21:17 ` Alex Williamson
2020-07-02 21:17 ` Alex Williamson
2020-07-03 6:08 ` Liu, Yi L
2020-07-03 6:08 ` Liu, Yi L
2020-06-24 8:55 ` [PATCH v3 05/14] iommu/vt-d: Support setting ioasid set to domain Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-06-24 8:55 ` [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free) Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-07-02 21:18 ` Alex Williamson
2020-07-02 21:18 ` Alex Williamson
2020-07-03 6:28 ` Liu, Yi L
2020-07-03 6:28 ` Liu, Yi L
2020-07-08 8:16 ` Liu, Yi L
2020-07-08 8:16 ` Liu, Yi L
2020-07-08 19:54 ` Alex Williamson
2020-07-08 19:54 ` Alex Williamson
2020-07-09 0:32 ` Liu, Yi L
2020-07-09 0:32 ` Liu, Yi L
2020-07-09 1:56 ` Tian, Kevin
2020-07-09 1:56 ` Tian, Kevin
2020-07-09 2:08 ` Liu, Yi L
2020-07-09 2:08 ` Liu, Yi L
2020-07-09 2:18 ` Tian, Kevin
2020-07-09 2:18 ` Tian, Kevin
2020-07-09 2:26 ` Liu, Yi L
2020-07-09 2:26 ` Liu, Yi L
2020-07-09 7:16 ` Liu, Yi L
2020-07-09 7:16 ` Liu, Yi L
2020-07-09 14:27 ` Alex Williamson
2020-07-09 14:27 ` Alex Williamson
2020-07-09 18:05 ` Jacob Pan [this message]
2020-07-09 18:05 ` Jacob Pan
2020-07-10 5:39 ` Liu, Yi L
2020-07-10 5:39 ` Liu, Yi L
2020-07-10 12:55 ` Alex Williamson
2020-07-10 12:55 ` Alex Williamson
2020-07-10 13:03 ` Liu, Yi L
2020-07-10 13:03 ` Liu, Yi L
2020-06-24 8:55 ` [PATCH v3 07/14] iommu: Pass domain to sva_unbind_gpasid() Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-06-24 8:55 ` [PATCH v3 08/14] iommu/vt-d: Check ownership for PASIDs from user-space Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-06-24 8:55 ` [PATCH v3 09/14] vfio/type1: Support binding guest page tables to PASID Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-07-02 21:19 ` Alex Williamson
2020-07-02 21:19 ` Alex Williamson
2020-07-03 6:46 ` Liu, Yi L
2020-07-03 6:46 ` Liu, Yi L
2020-06-24 8:55 ` [PATCH v3 10/14] vfio/type1: Allow invalidating first-level/stage IOMMU cache Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-07-02 21:19 ` Alex Williamson
2020-07-02 21:19 ` Alex Williamson
2020-07-03 3:47 ` Liu, Yi L
2020-07-03 3:47 ` Liu, Yi L
2020-06-24 8:55 ` [PATCH v3 11/14] vfio/type1: Add vSVA support for IOMMU-backed mdevs Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-06-24 8:55 ` [PATCH v3 12/14] vfio/pci: Expose PCIe PASID capability to guest Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-06-24 8:55 ` [PATCH v3 13/14] vfio: Document dual stage control Liu Yi L
2020-06-24 8:55 ` Liu Yi L
2020-06-29 9:21 ` Stefan Hajnoczi
2020-06-29 9:21 ` Stefan Hajnoczi
2020-06-29 9:24 ` Liu, Yi L
2020-06-29 9:24 ` Liu, Yi L
2020-06-24 8:55 ` [PATCH v3 14/14] iommu/vt-d: Support reporting nesting capability info Liu Yi L
2020-06-24 8:55 ` 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=20200709110513.3ff50f99@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=eric.auger@redhat.com \
--cc=hao.wu@intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=jun.j.tian@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterx@redhat.com \
--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.