On Thu, Oct 07, 2021 at 12:11:27PM -0700, Jacob Pan wrote:
> Hi Barry,
>
> On Thu, 7 Oct 2021 18:43:33 +1300, Barry Song <21cn...@gmail.com> wrote:
>
> > > > Security-wise, KVA respects kernel mapping. So permissions are better
> > > > enforced than pass-through and identity mapping.
> > >
> >
Hi Barry,
On Thu, 7 Oct 2021 18:43:33 +1300, Barry Song <21cn...@gmail.com> wrote:
> > > Security-wise, KVA respects kernel mapping. So permissions are better
> > > enforced than pass-through and identity mapping.
> >
> > Is this meaningful? Isn't the entire physical map still in the KVA and
>
Hi Jason,
On Thu, 7 Oct 2021 14:48:22 -0300, Jason Gunthorpe wrote:
> On Thu, Oct 07, 2021 at 10:50:10AM -0700, Jacob Pan wrote:
>
> > On platforms that are DMA snooped, this barrier is not needed. But I
> > think your point is that once we convert to DMA API, the sync/barrier
> > is covered
On Thu, Oct 07, 2021 at 10:50:10AM -0700, Jacob Pan wrote:
> On platforms that are DMA snooped, this barrier is not needed. But I think
> your point is that once we convert to DMA API, the sync/barrier is covered
> by DMA APIs if !dev_is_dma_coherent(dev). Then all archs are good.
No.. my point
Hi Jason,
On Thu, 7 Oct 2021 08:59:18 -0300, Jason Gunthorpe wrote:
> On Fri, Oct 08, 2021 at 12:54:52AM +1300, Barry Song wrote:
> > On Fri, Oct 8, 2021 at 12:32 AM Jason Gunthorpe wrote:
> >
> > >
> > > On Thu, Oct 07, 2021 at 06:43:33PM +1300, Barry Song wrote:
> > >
> > > > So do we
On Fri, Oct 08, 2021 at 12:54:52AM +1300, Barry Song wrote:
> On Fri, Oct 8, 2021 at 12:32 AM Jason Gunthorpe wrote:
> >
> > On Thu, Oct 07, 2021 at 06:43:33PM +1300, Barry Song wrote:
> >
> > > So do we have a case where devices can directly access the kernel's data
> > > structure such as a
On Fri, Oct 8, 2021 at 12:32 AM Jason Gunthorpe wrote:
>
> On Thu, Oct 07, 2021 at 06:43:33PM +1300, Barry Song wrote:
>
> > So do we have a case where devices can directly access the kernel's data
> > structure such as a list/graph/tree with pointers to a kernel virtual
> > address?
> > then
On Thu, Oct 07, 2021 at 06:43:33PM +1300, Barry Song wrote:
> So do we have a case where devices can directly access the kernel's data
> structure such as a list/graph/tree with pointers to a kernel virtual address?
> then devices don't need to translate the address of pointers in a structure.
>
On Tue, Oct 5, 2021 at 7:21 AM Jason Gunthorpe wrote:
>
> On Mon, Oct 04, 2021 at 09:40:03AM -0700, Jacob Pan wrote:
> > Hi Barry,
> >
> > On Sat, 2 Oct 2021 01:45:59 +1300, Barry Song <21cn...@gmail.com> wrote:
> >
> > > >
> > > > > I assume KVA mode can avoid this iotlb flush as the device is
On Mon, Oct 04, 2021 at 09:40:03AM -0700, Jacob Pan wrote:
> Hi Barry,
>
> On Sat, 2 Oct 2021 01:45:59 +1300, Barry Song <21cn...@gmail.com> wrote:
>
> > >
> > > > I assume KVA mode can avoid this iotlb flush as the device is using
> > > > the page table of the kernel and sharing the whole
Hi Barry,
On Sat, 2 Oct 2021 01:45:59 +1300, Barry Song <21cn...@gmail.com> wrote:
> >
> > > I assume KVA mode can avoid this iotlb flush as the device is using
> > > the page table of the kernel and sharing the whole kernel space. But
> > > will users be glad to accept this mode?
> >
> >
On Wed, Sep 22, 2021 at 5:14 PM Jacob Pan wrote:
>
> Hi Joerg/Jason/Christoph et all,
>
> The current in-kernel supervisor PASID support is based on the SVM/SVA
> machinery in sva-lib. Kernel SVA is achieved by extending a special flag
> to indicate the binding of the device and a page table
On Sat, Oct 2, 2021 at 1:36 AM Jason Gunthorpe wrote:
>
> On Sat, Oct 02, 2021 at 01:24:54AM +1300, Barry Song wrote:
>
> > I assume KVA mode can avoid this iotlb flush as the device is using
> > the page table of the kernel and sharing the whole kernel space. But
> > will users be glad to accept
On Sat, Oct 02, 2021 at 01:24:54AM +1300, Barry Song wrote:
> I assume KVA mode can avoid this iotlb flush as the device is using
> the page table of the kernel and sharing the whole kernel space. But
> will users be glad to accept this mode?
You can avoid the lock be identity mapping the
Hi Mike,
On Thu, 30 Sep 2021 14:22:34 +, "Campin, Mike"
wrote:
> I need support for mixed user PASID, kernel PASID and non-PASID use cases
> in the driver.
>
This specific RFC is for kernel PASID only. User PASID native use is
supported under SVA lib kernel API and /dev/uacce UAPI or
I need support for mixed user PASID, kernel PASID and non-PASID use cases in
the driver.
-Original Message-
From: Jason Gunthorpe
Sent: Wednesday, September 29, 2021 4:43 PM
To: Jacob Pan
Cc: iommu@lists.linux-foundation.org; LKML ;
Joerg Roedel ; Christoph Hellwig ; Tian,
Kevin ;
On Wed, Sep 29, 2021 at 03:57:20PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 29 Sep 2021 16:39:53 -0300, Jason Gunthorpe wrote:
>
> > On Wed, Sep 29, 2021 at 12:37:19PM -0700, Jacob Pan wrote:
> >
> > > For #2, it seems we can store the kernel PASID in struct device. This
> > > will
Hi Jason,
On Wed, 29 Sep 2021 16:39:53 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 29, 2021 at 12:37:19PM -0700, Jacob Pan wrote:
>
> > For #2, it seems we can store the kernel PASID in struct device. This
> > will preserve the DMA API interface while making it PASID capable.
> > Essentially,
On Wed, Sep 29, 2021 at 12:37:19PM -0700, Jacob Pan wrote:
> For #2, it seems we can store the kernel PASID in struct device. This will
> preserve the DMA API interface while making it PASID capable. Essentially,
> each PASID capable device would have two special global PASIDs:
> - PASID
Hi,
Just to follow up on what we discussed during LPC VFIO/IOMMU/PCI MC.
https://linuxplumbersconf.org/event/11/contributions/1021/
The key takeaways are:
1. Addressing mode selections (PA, IOVA, and KVA) should be a policy
decision *not* to be made by device drivers. This implies that it is up
On Tue, Sep 21, 2021 at 01:29:34PM -0700, Jacob Pan wrote:
> Hi Joerg/Jason/Christoph et all,
>
> The current in-kernel supervisor PASID support is based on the SVM/SVA
> machinery in sva-lib. Kernel SVA is achieved by extending a special flag
> to indicate the binding of the device and a page
21 matches
Mail list logo
