From: "Tian, Kevin" <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> To: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>, "Liu, Yi L" <yi.l.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> Cc: "Lan, Tianyu" <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>, "qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org" <qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>, "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "Pan, Jacob jun" <jacob.jun.pan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Subject: RE: [Qemu-devel] [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation Date: Wed, 5 Jul 2017 22:31:13 +0000 [thread overview] Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D190D2699E@SHSMSX101.ccr.corp.intel.com> (raw) In-Reply-To: <1d63c1ae-ca10-0f9d-91de-0d9c9823c104-5wv7dgnIgG8@public.gmane.org> > From: Jean-Philippe Brucker > Sent: Wednesday, July 5, 2017 8:42 PM > > On 05/07/17 07:45, Tian, Kevin wrote: > >> From: Liu, Yi L > >> Sent: Monday, July 3, 2017 6:31 PM > >> > >> Hi Jean, > >> > >> > >>> > >>>> 2. Define a structure in include/uapi/linux/iommu.h(newly added > header > >> file) > >>>> > >>>> struct iommu_tlb_invalidate { > >>>> __u32 scope; > >>>> /* pasid-selective invalidation described by @pasid */ > >>>> #define IOMMU_INVALIDATE_PASID (1 << 0) > >>>> /* address-selevtive invalidation described by (@vaddr, @size) */ > >>>> #define IOMMU_INVALIDATE_VADDR (1 << 1) > > > > For VT-d above two flags are related. There is no method of flushing > > (@vaddr, @size) for all pasids, which doesn't make sense. address- > > selective invalidation is valid only for a given pasid. So it's not appropriate > > to put them in same level of scope definition at least for VT-d. > > For ARM SMMU the "flush all by VA" operation is valid. Although it's > unclear at this point if we will ever allow that, it should probably stay > in the common format, if there is one. fine in common format. earlier I was thinking whether it should be in scope. possibly fine after another thinking. :-) > > >>>> __u32 flags; > >>>> /* targets non-pasid mappings, @pasid is not valid */ > >>>> #define IOMMU_INVALIDATE_NO_PASID (1 << 0) > >>> > >>> Although it was my proposal, I don't like this flag. In ARM SMMU, we're > >>> using a special mode where PASID 0 is reserved and any traffic without > >>> PASID uses entry 0 of the PASID table. So I proposed the "NO_PASID" flag > >>> to invalidate that special context explicitly. But this means that > >>> invalidation packet targeted at that context will have "scope = PASID" > and > >>> "flags = NO_PASID", which is utterly confusing. > >>> > >>> I now think that we should get rid of the > IOMMU_INVALIDATE_NO_PASID > >> flag > >>> and just use PASID 0 to invalidate this context on ARM. I don't think > >>> other architectures would use the NO_PASID flag anyway, but might be > >> mistaken. > >> > >> I may suggest to keep it so far. On VT-d, we may pass some data in > opaque, > >> so > >> we may work without it. But if other vendor want to issue non-PASID > tagged > >> cache, then may encounter problem. > > > > I'm worried about what's the criteria which attribute should be abstracted > > in common structure and which can be left to opaque. It doesn't make > > much sense to do such abstraction purely because different vendor > formats > > have some common fields. Usually we do such abstraction because > > vendor-agnostic code need to do some common handling before going to > > vendor specific code. However in this case VFIO is not expected to do > anything > > with those IOMMU specific attributes. Then the structure is directly > forwarded > > to IOMMU driver, which simply translates the structure into vendor specific > > opaque data again. Then why bothering to do double translations in Qemu > > and IOMMU driver side?> > > Take VT-d for example. Below is a summary of all possible selections > around > > invalidation of 1st level structure for svm: > > > > Scope: All PASIDs, single PASID > > for each PASID: > > all mappings, or page-selective mappings (addr, size) > > invalidation target: > > IOTLB entries (leaf) > > paging structure cache (non-leaf) > > I'm curious, can you invalidate all intermediate paging structures for a > given PASID without invalidating the leaves? I don't think so. usually IOTLB flush is the base. one can further specify whether flush should apply to non-leaves. Thanks Kevin
WARNING: multiple messages have this Message-ID (diff)
From: "Tian, Kevin" <kevin.tian@intel.com> To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>, "Liu, Yi L" <yi.l.liu@linux.intel.com> Cc: "Lan, Tianyu" <tianyu.lan@intel.com>, "Liu, Yi L" <yi.l.liu@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "jasowang@redhat.com" <jasowang@redhat.com>, Will Deacon <Will.Deacon@arm.com>, "alex.williamson@redhat.com" <alex.williamson@redhat.com>, "peterx@redhat.com" <peterx@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "Pan, Jacob jun" <jacob.jun.pan@intel.com> Subject: Re: [Qemu-devel] [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation Date: Wed, 5 Jul 2017 22:31:13 +0000 [thread overview] Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D190D2699E@SHSMSX101.ccr.corp.intel.com> (raw) In-Reply-To: <1d63c1ae-ca10-0f9d-91de-0d9c9823c104@arm.com> > From: Jean-Philippe Brucker > Sent: Wednesday, July 5, 2017 8:42 PM > > On 05/07/17 07:45, Tian, Kevin wrote: > >> From: Liu, Yi L > >> Sent: Monday, July 3, 2017 6:31 PM > >> > >> Hi Jean, > >> > >> > >>> > >>>> 2. Define a structure in include/uapi/linux/iommu.h(newly added > header > >> file) > >>>> > >>>> struct iommu_tlb_invalidate { > >>>> __u32 scope; > >>>> /* pasid-selective invalidation described by @pasid */ > >>>> #define IOMMU_INVALIDATE_PASID (1 << 0) > >>>> /* address-selevtive invalidation described by (@vaddr, @size) */ > >>>> #define IOMMU_INVALIDATE_VADDR (1 << 1) > > > > For VT-d above two flags are related. There is no method of flushing > > (@vaddr, @size) for all pasids, which doesn't make sense. address- > > selective invalidation is valid only for a given pasid. So it's not appropriate > > to put them in same level of scope definition at least for VT-d. > > For ARM SMMU the "flush all by VA" operation is valid. Although it's > unclear at this point if we will ever allow that, it should probably stay > in the common format, if there is one. fine in common format. earlier I was thinking whether it should be in scope. possibly fine after another thinking. :-) > > >>>> __u32 flags; > >>>> /* targets non-pasid mappings, @pasid is not valid */ > >>>> #define IOMMU_INVALIDATE_NO_PASID (1 << 0) > >>> > >>> Although it was my proposal, I don't like this flag. In ARM SMMU, we're > >>> using a special mode where PASID 0 is reserved and any traffic without > >>> PASID uses entry 0 of the PASID table. So I proposed the "NO_PASID" flag > >>> to invalidate that special context explicitly. But this means that > >>> invalidation packet targeted at that context will have "scope = PASID" > and > >>> "flags = NO_PASID", which is utterly confusing. > >>> > >>> I now think that we should get rid of the > IOMMU_INVALIDATE_NO_PASID > >> flag > >>> and just use PASID 0 to invalidate this context on ARM. I don't think > >>> other architectures would use the NO_PASID flag anyway, but might be > >> mistaken. > >> > >> I may suggest to keep it so far. On VT-d, we may pass some data in > opaque, > >> so > >> we may work without it. But if other vendor want to issue non-PASID > tagged > >> cache, then may encounter problem. > > > > I'm worried about what's the criteria which attribute should be abstracted > > in common structure and which can be left to opaque. It doesn't make > > much sense to do such abstraction purely because different vendor > formats > > have some common fields. Usually we do such abstraction because > > vendor-agnostic code need to do some common handling before going to > > vendor specific code. However in this case VFIO is not expected to do > anything > > with those IOMMU specific attributes. Then the structure is directly > forwarded > > to IOMMU driver, which simply translates the structure into vendor specific > > opaque data again. Then why bothering to do double translations in Qemu > > and IOMMU driver side?> > > Take VT-d for example. Below is a summary of all possible selections > around > > invalidation of 1st level structure for svm: > > > > Scope: All PASIDs, single PASID > > for each PASID: > > all mappings, or page-selective mappings (addr, size) > > invalidation target: > > IOTLB entries (leaf) > > paging structure cache (non-leaf) > > I'm curious, can you invalidate all intermediate paging structures for a > given PASID without invalidating the leaves? I don't think so. usually IOTLB flush is the base. one can further specify whether flush should apply to non-leaves. Thanks Kevin
next prev parent reply other threads:[~2017-07-05 22:31 UTC|newest] Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-26 10:11 [RFC PATCH 0/8] Shared Virtual Memory virtualization for VT-d Liu, Yi L 2017-04-26 10:11 ` [Qemu-devel] " Liu, Yi L 2017-04-26 10:11 ` [RFC PATCH 1/8] iommu: Introduce bind_pasid_table API function Liu, Yi L 2017-04-26 10:11 ` [Qemu-devel] " Liu, Yi L 2017-04-26 16:56 ` Jean-Philippe Brucker 2017-04-26 16:56 ` [Qemu-devel] " Jean-Philippe Brucker 2017-04-27 6:36 ` Liu, Yi L 2017-04-27 6:36 ` [Qemu-devel] " Liu, Yi L 2017-04-27 10:12 ` Jean-Philippe Brucker 2017-04-27 10:12 ` [Qemu-devel] " Jean-Philippe Brucker [not found] ` <772ca9de-50ba-a379-002d-5ff1f6a2e297-5wv7dgnIgG8@public.gmane.org> 2017-04-28 7:59 ` Liu, Yi L 2017-04-28 7:59 ` Liu, Yi L [not found] ` <c042bf90-d48b-4ebf-c01a-fca7c4875277-5wv7dgnIgG8@public.gmane.org> 2017-04-26 18:29 ` jacob pan 2017-04-26 18:29 ` [Qemu-devel] " jacob pan [not found] ` <20170426112948.00004520-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2017-04-26 18:59 ` Jean-Philippe Brucker 2017-04-26 18:59 ` [Qemu-devel] " Jean-Philippe Brucker 2017-04-28 9:04 ` Liu, Yi L 2017-04-28 9:04 ` Liu, Yi L 2017-04-28 12:51 ` Jean-Philippe Brucker 2017-04-28 12:51 ` Jean-Philippe Brucker [not found] ` <3adb4e33-db96-4133-0510-412c3bfb24fe-5wv7dgnIgG8@public.gmane.org> 2017-05-23 7:50 ` Liu, Yi L 2017-05-23 7:50 ` Liu, Yi L 2017-05-25 12:33 ` Jean-Philippe Brucker 2017-05-25 12:33 ` Jean-Philippe Brucker [not found] ` <1493201525-14418-2-git-send-email-yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2017-05-12 21:59 ` Alex Williamson 2017-05-12 21:59 ` [Qemu-devel] " Alex Williamson [not found] ` <20170512155914.73bad777-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org> 2017-05-14 10:56 ` Liu, Yi L 2017-05-14 10:56 ` [Qemu-devel] " Liu, Yi L 2017-04-26 10:11 ` [RFC PATCH 2/8] iommu/vt-d: add bind_pasid_table function Liu, Yi L 2017-04-26 10:11 ` [Qemu-devel] " Liu, Yi L [not found] ` <1493201525-14418-3-git-send-email-yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2017-05-12 21:59 ` Alex Williamson 2017-05-12 21:59 ` [Qemu-devel] " Alex Williamson [not found] ` <20170512155929.66809113-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org> 2017-05-15 13:14 ` jacob pan 2017-05-15 13:14 ` [Qemu-devel] " jacob pan 2017-04-26 10:12 ` [RFC PATCH 3/8] iommu: Introduce iommu do invalidate API function Liu, Yi L 2017-04-26 10:12 ` [Qemu-devel] " Liu, Yi L [not found] ` <1493201525-14418-4-git-send-email-yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2017-05-12 21:59 ` Alex Williamson 2017-05-12 21:59 ` [Qemu-devel] " Alex Williamson [not found] ` <20170512155924.755ee17f-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org> 2017-05-17 10:23 ` Liu, Yi L 2017-05-17 10:23 ` [Qemu-devel] " Liu, Yi L 2017-04-26 10:12 ` [RFC PATCH 4/8] iommu/vt-d: Add iommu do invalidate function Liu, Yi L 2017-04-26 10:12 ` [Qemu-devel] " Liu, Yi L [not found] ` <1493201525-14418-5-git-send-email-yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2017-05-12 21:59 ` Alex Williamson 2017-05-12 21:59 ` [Qemu-devel] " Alex Williamson [not found] ` <20170512155918.5251fb94-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org> 2017-05-17 10:24 ` Liu, Yi L 2017-05-17 10:24 ` [Qemu-devel] " Liu, Yi L 2017-04-26 10:12 ` [RFC PATCH 5/8] VFIO: Add new IOTCL for PASID Table bind propagation Liu, Yi L 2017-04-26 10:12 ` [Qemu-devel] " Liu, Yi L 2017-04-26 16:56 ` Jean-Philippe Brucker 2017-04-26 16:56 ` [Qemu-devel] " Jean-Philippe Brucker 2017-04-27 5:43 ` Liu, Yi L [not found] ` <1493201525-14418-6-git-send-email-yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> 2017-05-11 10:29 ` Liu, Yi L 2017-05-11 10:29 ` Liu, Yi L 2017-05-12 21:58 ` Alex Williamson 2017-05-12 21:58 ` [Qemu-devel] " Alex Williamson [not found] ` <20170512155851.627409ed-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org> 2017-05-17 10:27 ` Liu, Yi L 2017-05-17 10:27 ` Liu, Yi L [not found] ` <20170517102759.GF22110-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-05-18 11:29 ` Jean-Philippe Brucker 2017-05-18 11:29 ` Jean-Philippe Brucker 2017-04-26 10:12 ` [RFC PATCH 6/8] VFIO: do pasid table binding Liu, Yi L 2017-04-26 10:12 ` [Qemu-devel] " Liu, Yi L 2017-05-09 7:55 ` Xiao Guangrong 2017-05-09 7:55 ` [Qemu-devel] " Xiao Guangrong 2017-05-11 10:29 ` Liu, Yi L 2017-05-12 21:59 ` Alex Williamson 2017-05-12 21:59 ` [Qemu-devel] " Alex Williamson 2017-04-26 10:12 ` [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation Liu, Yi L 2017-04-26 10:12 ` [Qemu-devel] " Liu, Yi L 2017-05-12 12:11 ` Jean-Philippe Brucker 2017-05-12 12:11 ` [Qemu-devel] " Jean-Philippe Brucker [not found] ` <cc330a8f-e087-9b6f-2a40-38b58688d300-5wv7dgnIgG8@public.gmane.org> 2017-05-14 10:12 ` Liu, Yi L 2017-05-14 10:12 ` [Qemu-devel] " Liu, Yi L 2017-05-15 12:14 ` Jean-Philippe Brucker 2017-05-15 12:14 ` [Qemu-devel] " Jean-Philippe Brucker 2017-07-02 10:06 ` Liu, Yi L 2017-07-02 10:06 ` Liu, Yi L 2017-07-03 11:52 ` Jean-Philippe Brucker [not found] ` <0e4f2dd4-d553-b1b7-7bec-fe0ff5242c54-5wv7dgnIgG8@public.gmane.org> 2017-07-03 10:31 ` Liu, Yi L 2017-07-03 10:31 ` Liu, Yi L [not found] ` <20170703103115.GB22053-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-07-05 6:45 ` Tian, Kevin 2017-07-05 6:45 ` Tian, Kevin [not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D190D25919-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-07-05 12:42 ` Jean-Philippe Brucker 2017-07-05 12:42 ` Jean-Philippe Brucker [not found] ` <1d63c1ae-ca10-0f9d-91de-0d9c9823c104-5wv7dgnIgG8@public.gmane.org> 2017-07-05 17:28 ` Alex Williamson 2017-07-05 17:28 ` Alex Williamson [not found] ` <20170705112816.56554f65-DGNDKt5SQtizQB+pC5nmwQ@public.gmane.org> 2017-07-05 22:26 ` Tian, Kevin 2017-07-05 22:26 ` Tian, Kevin 2017-07-14 8:58 ` Liu, Yi L 2017-07-14 8:58 ` Liu, Yi L [not found] ` <A2975661238FB949B60364EF0F2C2574390A7C4F-E2R4CRU6q/6iAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-07-14 18:15 ` Alex Williamson 2017-07-14 18:15 ` Alex Williamson [not found] ` <20170714121555.7e64d849-DGNDKt5SQtizQB+pC5nmwQ@public.gmane.org> 2017-07-17 10:58 ` Liu, Yi L 2017-07-17 10:58 ` Liu, Yi L 2017-07-17 22:45 ` Alex Williamson [not found] ` <20170717164515.2491b3bf-DGNDKt5SQtizQB+pC5nmwQ@public.gmane.org> 2017-07-18 9:38 ` Jean-Philippe Brucker 2017-07-18 9:38 ` Jean-Philippe Brucker [not found] ` <d0abeefc-adcf-85c3-f5d9-8c90a18f8011-5wv7dgnIgG8@public.gmane.org> 2017-07-18 14:29 ` Alex Williamson 2017-07-18 14:29 ` Alex Williamson 2017-07-18 15:03 ` Jean-Philippe Brucker 2017-07-19 10:45 ` Liu, Yi L 2017-07-19 10:45 ` Liu, Yi L 2017-07-19 21:50 ` Jacob Pan 2017-07-19 21:50 ` Jacob Pan 2017-07-05 22:31 ` Tian, Kevin [this message] 2017-07-05 22:31 ` Tian, Kevin 2017-05-12 21:58 ` Alex Williamson 2017-05-12 21:58 ` [Qemu-devel] " Alex Williamson 2017-05-14 10:55 ` Liu, Yi L 2017-05-14 10:55 ` [Qemu-devel] " Liu, Yi L [not found] ` <20170514105507.GB22110-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-07-05 5:32 ` Tian, Kevin 2017-07-05 5:32 ` [Qemu-devel] " Tian, Kevin 2017-04-26 10:12 ` [RFC PATCH 8/8] VFIO: do IOMMU TLB invalidation from guest Liu, Yi L 2017-04-26 10:12 ` [Qemu-devel] " Liu, Yi L 2017-05-08 4:09 ` [RFC PATCH 0/8] Shared Virtual Memory virtualization for VT-d Xiao Guangrong 2017-05-08 4:09 ` [Qemu-devel] " Xiao Guangrong 2017-05-07 7:33 ` 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=AADFC41AFE54684AB9EE6CBC0274A5D190D2699E@SHSMSX101.ccr.corp.intel.com \ --to=kevin.tian-ral2jqcrhueavxtiumwx3w@public.gmane.org \ --cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=jacob.jun.pan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=jasowang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org \ --cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \ --cc=tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=yi.l.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \ /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: linkBe 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.