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 by
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 i
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 hav
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 list
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 dev
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.
> I
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 us
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 kern
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?
> >
> > You
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 shoul
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 physica
ke ; Thomas Gleixner
> Subject: Re: [RFC 0/7] Support in-kernel DMA with
> PASID and SVA
>
> 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,
; Luck, Tony ; Jiang, Dave
; Raj, Ashok ; Kumar, Sanjay K
; Campin, Mike ; Thomas
Gleixner
Subject: Re: [RFC 0/7] Support in-kernel DMA with PASID and SVA
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 Gunthor
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 pres
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 0
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 to
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 tab
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 should be performed
on init_mm instead of the mm of the current pr
22 matches
Mail list logo
