Hi Jason,
On Mon, 17 May 2021 11:37:58 -0300, Jason Gunthorpe wrote:
> On Thu, May 13, 2021 at 04:40:28PM -0700, Jacob Pan wrote:
>
> > Looks like we are converging. Let me summarize the takeaways:
> > 1. Remove IOMMU_SVA_BIND_SUPERVISOR flag from this patch, in fact there
> > will be no flags
On Thu, May 13, 2021 at 04:40:28PM -0700, Jacob Pan wrote:
> Looks like we are converging. Let me summarize the takeaways:
> 1. Remove IOMMU_SVA_BIND_SUPERVISOR flag from this patch, in fact there
> will be no flags at all for iommu_sva_bind_device()
> 2. Remove all supervisor SVA related vt-d,
Hi Jason,
On Thu, 13 May 2021 19:31:22 -0300, Jason Gunthorpe wrote:
> On Thu, May 13, 2021 at 01:22:51PM -0700, Jacob Pan wrote:
> > Hi Tony,
> >
> > On Thu, 13 May 2021 12:57:49 -0700, "Luck, Tony"
> > wrote:
> >
> > > On Thu, May 13, 2021 at 12:46:21PM -0700, Jacob Pan wrote:
> > > >
On Thu, May 13, 2021 at 01:22:51PM -0700, Jacob Pan wrote:
> Hi Tony,
>
> On Thu, 13 May 2021 12:57:49 -0700, "Luck, Tony"
> wrote:
>
> > On Thu, May 13, 2021 at 12:46:21PM -0700, Jacob Pan wrote:
> > > It seems there are two options:
> > > 1. Add a new IOMMU API to set up a system PASID with a
Hi Tony,
On Thu, 13 May 2021 12:57:49 -0700, "Luck, Tony"
wrote:
> On Thu, May 13, 2021 at 12:46:21PM -0700, Jacob Pan wrote:
> > It seems there are two options:
> > 1. Add a new IOMMU API to set up a system PASID with a *separate* IOMMU
> > page table/domain, mark the device is PASID only with
On Thu, May 13, 2021 at 12:46:21PM -0700, Jacob Pan wrote:
> It seems there are two options:
> 1. Add a new IOMMU API to set up a system PASID with a *separate* IOMMU page
> table/domain, mark the device is PASID only with a flag. Use DMA APIs
> to explicit map/unmap. Based on this PASID-only
Hi Jason,
On Thu, 13 May 2021 16:20:14 -0300, Jason Gunthorpe wrote:
> On Thu, May 13, 2021 at 07:14:54PM +, Luck, Tony wrote:
> > > If you want this then be explicit about what it is you are making when
> > > building the API. Don't try to hide it under some generic idea of
> > > "kernel
On Thu, May 13, 2021 at 07:14:54PM +, Luck, Tony wrote:
> > If you want this then be explicit about what it is you are making when
> > building the API. Don't try to hide it under some generic idea of
> > "kernel PCI DMA SVA"
>
> So, a special API call (that Dave can call from IDXD) to set up
> If you want this then be explicit about what it is you are making when
> building the API. Don't try to hide it under some generic idea of
> "kernel PCI DMA SVA"
So, a special API call (that Dave can call from IDXD) to set up this
kernel PASID. With suitable documentation to explain the scope.
On Thu, May 13, 2021 at 11:53:49AM -0700, Luck, Tony wrote:
> I'd like people to think of DSA as an extension to the instruction
> set. It implements asynchronous instructions like "MEMFILL" and
> "MEMCOPY". These can be limited in scope when executed in user
> processes or guests. But when
On Thu, May 13, 2021 at 02:33:03PM -0300, Jason Gunthorpe wrote:
> The page table under the kernel PASID should behave the same way that
> the kernel would operate the page table assigned to a kernel RID.
>
> If the kernel has security off then the PASID should map to all
> physical memory, just
On Thu, May 13, 2021 at 04:44:14PM +, Luck, Tony wrote:
> > For shared workqueue, it can only generate DMA request with PASID. The
> > submission is done by ENQCMDS (S for supervisor) instruction.
> >
> > If we were not to share page tables with init_mm, we need a system PASID
> > that doing
> For shared workqueue, it can only generate DMA request with PASID. The
> submission is done by ENQCMDS (S for supervisor) instruction.
>
> If we were not to share page tables with init_mm, we need a system PASID
> that doing the same direct mapping in IOMMU page tables.
Note that for the
Hi Jason,
On Thu, 13 May 2021 10:38:34 -0300, Jason Gunthorpe wrote:
> On Thu, May 13, 2021 at 06:00:12AM -0700, Jacob Pan wrote:
> > > > If you want to do SVA PASID then it also must come with DMA APIs to
> > > > manage the CPU cache coherence that are all NOP's on x86.
> > >
> > > Yes.
On Thu, May 13, 2021 at 06:00:12AM -0700, Jacob Pan wrote:
> > > If you want to do SVA PASID then it also must come with DMA APIs to
> > > manage the CPU cache coherence that are all NOP's on x86.
> >
> > Yes. And we have plenty of precende where an IOMMU is in "bypass" mode
> > to allow
Hi Christoph,
On Wed, 12 May 2021 07:37:40 +0100, Christoph Hellwig
wrote:
> On Tue, May 11, 2021 at 04:47:26PM -0300, Jason Gunthorpe wrote:
> > > Let me try to break down your concerns:
> > > 1. portability - driver uses DMA APIs can function w/ and w/o IOMMU.
> > > is that your concern? But
On Mon, May 10, 2021 at 06:25:07AM -0700, Jacob Pan wrote:
> The void* drvdata parameter isn't really used in iommu_sva_bind_device()
> API, the current IDXD code "borrows" the drvdata for a VT-d private flag
> for supervisor SVA usage.
>
> Supervisor/Privileged mode request is a generic feature.
On Tue, May 11, 2021 at 04:47:26PM -0300, Jason Gunthorpe wrote:
> > Let me try to break down your concerns:
> > 1. portability - driver uses DMA APIs can function w/ and w/o IOMMU. is
> > that your concern? But PASID is intrinsically tied with IOMMU and if
> > the drivers are using a generic
On Tue, May 11, 2021 at 11:05:50AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Tue, 11 May 2021 13:35:21 -0300, Jason Gunthorpe wrote:
>
> > On Tue, May 11, 2021 at 09:14:52AM -0700, Jacob Pan wrote:
> >
> > > > Honestly, I'm not convinced we should have "kernel SVA" at all.. Why
> > > > does
Hi Jason,
On Tue, 11 May 2021 13:35:21 -0300, Jason Gunthorpe wrote:
> On Tue, May 11, 2021 at 09:14:52AM -0700, Jacob Pan wrote:
>
> > > Honestly, I'm not convinced we should have "kernel SVA" at all.. Why
> > > does IDXD use normal DMA on the RID for kernel controlled accesses?
> >
> >
On Tue, May 11, 2021 at 09:14:52AM -0700, Jacob Pan wrote:
> > Honestly, I'm not convinced we should have "kernel SVA" at all.. Why
> > does IDXD use normal DMA on the RID for kernel controlled accesses?
>
> Using SVA simplifies the work submission, there is no need to do map/unmap.
> Just bind
Hi Jason,
On Tue, 11 May 2021 08:48:48 -0300, Jason Gunthorpe wrote:
> On Mon, May 10, 2021 at 08:31:45PM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Mon, 10 May 2021 20:37:49 -0300, Jason Gunthorpe
> > wrote:
> > > On Mon, May 10, 2021 at 06:25:07AM -0700, Jacob Pan wrote:
> > >
> >
On Mon, May 10, 2021 at 08:31:45PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Mon, 10 May 2021 20:37:49 -0300, Jason Gunthorpe 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
> > >
Hi Jason,
On Mon, 10 May 2021 20:37:49 -0300, Jason Gunthorpe 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
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
The void* drvdata parameter isn't really used in iommu_sva_bind_device()
API, the current IDXD code "borrows" the drvdata for a VT-d private flag
for supervisor SVA usage.
Supervisor/Privileged mode request is a generic feature. It should be
promoted from the VT-d vendor driver to the generic
26 matches
Mail list logo
