From: Jacob Pan <jacob.jun.pan@linux.intel.com> To: Jason Gunthorpe <jgg@nvidia.com> Cc: LKML <linux-kernel@vger.kernel.org>, iommu@lists.linux-foundation.org, Joerg Roedel <joro@8bytes.org>, Lu Baolu <baolu.lu@linux.intel.com>, Jean-Philippe Brucker <jean-philippe@linaro.com>, Christoph Hellwig <hch@infradead.org>, Yi Liu <yi.l.liu@intel.com>, Raj Ashok <ashok.raj@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>, Dave Jiang <dave.jiang@intel.com>, wangzhou1@hisilicon.com, zhangfei.gao@linaro.org, vkoul@kernel.org, jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit flags Date: Mon, 10 May 2021 20:31:45 -0700 [thread overview] Message-ID: <20210510203145.086835cc@jacob-builder> (raw) In-Reply-To: <20210510233749.GG1002214@nvidia.com> Hi Jason, On Mon, 10 May 2021 20:37:49 -0300, Jason Gunthorpe <jgg@nvidia.com> wrote: > On Mon, May 10, 2021 at 06:25:07AM -0700, Jacob Pan wrote: > > > +/* > > + * The IOMMU_SVA_BIND_SUPERVISOR flag requests a PASID which can be > > used only > > + * for access to kernel addresses. No IOTLB flushes are automatically > > done > > + * for kernel mappings; it is valid only for access to the kernel's > > static > > + * 1:1 mapping of physical memory — not to vmalloc or even module > > mappings. > > + * A future API addition may permit the use of such ranges, by means > > of an > > + * explicit IOTLB flush call (akin to the DMA API's unmap method). > > + * > > + * It is unlikely that we will ever hook into flush_tlb_kernel_range() > > to > > + * do such IOTLB flushes automatically. > > + */ > > +#define IOMMU_SVA_BIND_SUPERVISOR BIT(0) > > Huh? That isn't really SVA, can you call it something saner please? > This is shared kernel virtual address, I am following the SVA lib naming since this is where the flag will be used. Why this is not SVA? Kernel virtual address is still virtual address. Is it due to direct map? > Is it really a PASID that always has all of physical memory mapped > into it? Sounds dangerous. What is it for? > Yes. It is to bind DMA request w/ PASID with init_mm/init_top_pgt. Per PCIe spec PASID TLP prefix has "Privileged Mode Requested" bit. VT-d supports this with "Privileged-mode-Requested (PR) flag (to distinguish user versus supervisor access)". Each PASID entry has a SRE (Supervisor Request Enable) bit. Perhaps we should limit that to trusted device, e.g. RCIEP device? > Jason Thanks, Jacob
WARNING: multiple messages have this Message-ID (diff)
From: Jacob Pan <jacob.jun.pan@linux.intel.com> To: Jason Gunthorpe <jgg@nvidia.com> Cc: vkoul@kernel.org, "Tian, Kevin" <kevin.tian@intel.com>, Dave Jiang <dave.jiang@intel.com>, Raj Ashok <ashok.raj@intel.com>, LKML <linux-kernel@vger.kernel.org>, Christoph Hellwig <hch@infradead.org>, iommu@lists.linux-foundation.org, zhangfei.gao@linaro.org, Jean-Philippe Brucker <jean-philippe@linaro.com> Subject: Re: [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit flags Date: Mon, 10 May 2021 20:31:45 -0700 [thread overview] Message-ID: <20210510203145.086835cc@jacob-builder> (raw) In-Reply-To: <20210510233749.GG1002214@nvidia.com> Hi Jason, On Mon, 10 May 2021 20:37:49 -0300, Jason Gunthorpe <jgg@nvidia.com> wrote: > On Mon, May 10, 2021 at 06:25:07AM -0700, Jacob Pan wrote: > > > +/* > > + * The IOMMU_SVA_BIND_SUPERVISOR flag requests a PASID which can be > > used only > > + * for access to kernel addresses. No IOTLB flushes are automatically > > done > > + * for kernel mappings; it is valid only for access to the kernel's > > static > > + * 1:1 mapping of physical memory — not to vmalloc or even module > > mappings. > > + * A future API addition may permit the use of such ranges, by means > > of an > > + * explicit IOTLB flush call (akin to the DMA API's unmap method). > > + * > > + * It is unlikely that we will ever hook into flush_tlb_kernel_range() > > to > > + * do such IOTLB flushes automatically. > > + */ > > +#define IOMMU_SVA_BIND_SUPERVISOR BIT(0) > > Huh? That isn't really SVA, can you call it something saner please? > This is shared kernel virtual address, I am following the SVA lib naming since this is where the flag will be used. Why this is not SVA? Kernel virtual address is still virtual address. Is it due to direct map? > Is it really a PASID that always has all of physical memory mapped > into it? Sounds dangerous. What is it for? > Yes. It is to bind DMA request w/ PASID with init_mm/init_top_pgt. Per PCIe spec PASID TLP prefix has "Privileged Mode Requested" bit. VT-d supports this with "Privileged-mode-Requested (PR) flag (to distinguish user versus supervisor access)". Each PASID entry has a SRE (Supervisor Request Enable) bit. Perhaps we should limit that to trusted device, e.g. RCIEP device? > Jason Thanks, Jacob _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-05-11 3:29 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-10 13:25 [PATCH v4 0/2] Simplify and restrict IOMMU SVA APIs Jacob Pan 2021-05-10 13:25 ` Jacob Pan 2021-05-10 13:25 ` [PATCH v4 1/2] iommu/sva: Tighten SVA bind API with explicit flags Jacob Pan 2021-05-10 13:25 ` Jacob Pan 2021-05-10 23:37 ` Jason Gunthorpe 2021-05-10 23:37 ` Jason Gunthorpe 2021-05-11 3:31 ` Jacob Pan [this message] 2021-05-11 3:31 ` Jacob Pan 2021-05-11 11:48 ` Jason Gunthorpe 2021-05-11 11:48 ` Jason Gunthorpe 2021-05-11 16:14 ` Jacob Pan 2021-05-11 16:14 ` Jacob Pan 2021-05-11 16:35 ` Jason Gunthorpe 2021-05-11 16:35 ` Jason Gunthorpe 2021-05-11 18:05 ` Jacob Pan 2021-05-11 18:05 ` Jacob Pan 2021-05-11 19:47 ` Jason Gunthorpe 2021-05-11 19:47 ` Jason Gunthorpe 2021-05-12 6:37 ` Christoph Hellwig 2021-05-12 6:37 ` Christoph Hellwig 2021-05-13 13:00 ` Jacob Pan 2021-05-13 13:00 ` Jacob Pan 2021-05-13 13:38 ` Jason Gunthorpe 2021-05-13 13:38 ` Jason Gunthorpe 2021-05-13 15:10 ` Jacob Pan 2021-05-13 15:10 ` Jacob Pan 2021-05-13 16:44 ` Luck, Tony 2021-05-13 16:44 ` Luck, Tony 2021-05-13 17:33 ` Jason Gunthorpe 2021-05-13 17:33 ` Jason Gunthorpe 2021-05-13 18:53 ` Luck, Tony 2021-05-13 18:53 ` Luck, Tony 2021-05-13 19:00 ` Jason Gunthorpe 2021-05-13 19:00 ` Jason Gunthorpe 2021-05-13 19:14 ` Luck, Tony 2021-05-13 19:14 ` Luck, Tony 2021-05-13 19:20 ` Jason Gunthorpe 2021-05-13 19:20 ` Jason Gunthorpe 2021-05-13 19:46 ` Jacob Pan 2021-05-13 19:46 ` Jacob Pan 2021-05-13 19:57 ` Luck, Tony 2021-05-13 19:57 ` Luck, Tony 2021-05-13 20:22 ` Jacob Pan 2021-05-13 20:22 ` Jacob Pan 2021-05-13 22:31 ` Jason Gunthorpe 2021-05-13 22:31 ` Jason Gunthorpe 2021-05-13 23:40 ` Jacob Pan 2021-05-13 23:40 ` Jacob Pan 2021-05-17 14:37 ` Jason Gunthorpe 2021-05-17 14:37 ` Jason Gunthorpe 2021-05-19 15:46 ` Jacob Pan 2021-05-19 15:46 ` Jacob Pan 2021-05-12 10:18 ` Jean-Philippe Brucker 2021-05-12 10:18 ` Jean-Philippe Brucker 2021-05-10 13:25 ` [PATCH v4 2/2] iommu/sva: Remove mm parameter from SVA bind API Jacob Pan 2021-05-10 13:25 ` Jacob Pan 2021-05-12 10:24 ` Jean-Philippe Brucker 2021-05-12 10:24 ` Jean-Philippe Brucker
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=20210510203145.086835cc@jacob-builder \ --to=jacob.jun.pan@linux.intel.com \ --cc=ashok.raj@intel.com \ --cc=baolu.lu@linux.intel.com \ --cc=dave.jiang@intel.com \ --cc=hch@infradead.org \ --cc=iommu@lists.linux-foundation.org \ --cc=jean-philippe@linaro.com \ --cc=jgg@nvidia.com \ --cc=joro@8bytes.org \ --cc=kevin.tian@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=vkoul@kernel.org \ --cc=wangzhou1@hisilicon.com \ --cc=yi.l.liu@intel.com \ --cc=zhangfei.gao@linaro.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.