On Fri, Apr 16, 2021 at 10:23:32AM -0700, Jacob Pan wrote:
> Perhaps similar to cgroup v1 vs v2, it took a long time and with known
> limitations in v1.
cgroup v2 is still having transition problems, if anything it is a
cautionary tale to think really hard about uAPI because transitioning
can be
Hi Alex,
On Fri, 16 Apr 2021 09:45:47 -0600, Alex Williamson
wrote:
> On Fri, 16 Apr 2021 06:12:58 -0700
> Jacob Pan wrote:
>
> > Hi Jason,
> >
> > On Thu, 15 Apr 2021 20:07:32 -0300, Jason Gunthorpe
> > wrote:
> > > On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
> > > >
On Fri, 16 Apr 2021 06:12:58 -0700
Jacob Pan wrote:
> Hi Jason,
>
> On Thu, 15 Apr 2021 20:07:32 -0300, Jason Gunthorpe wrote:
>
> > On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
> > > Hi Jason,
> > >
> > > On 4/1/21 6:03 PM, Jason Gunthorpe wrote:
> > > > On Thu, Apr 01,
Hi Jason,
On 4/16/21 4:34 PM, Jason Gunthorpe wrote:
> On Fri, Apr 16, 2021 at 04:26:19PM +0200, Auger Eric wrote:
>
>> This was largely done during several confs including plumber, KVM forum,
>> for several years. Also API docs were shared on the ML. I don't remember
>> any voice was raised at
On Fri, Apr 16, 2021 at 04:26:19PM +0200, Auger Eric wrote:
> This was largely done during several confs including plumber, KVM forum,
> for several years. Also API docs were shared on the ML. I don't remember
> any voice was raised at those moments.
I don't think anyone objects to the high
Hi,
On 4/16/21 4:05 PM, Jason Gunthorpe wrote:
> On Fri, Apr 16, 2021 at 03:38:02PM +0200, Auger Eric wrote:
>
>> The redesign requirement came pretty late in the development process.
>> The iommu user API is upstream for a while, the VFIO interfaces have
>> been submitted a long time ago and
On Fri, Apr 16, 2021 at 03:38:02PM +0200, Auger Eric wrote:
> The redesign requirement came pretty late in the development process.
> The iommu user API is upstream for a while, the VFIO interfaces have
> been submitted a long time ago and under review for a bunch of time.
> Redesigning
Hi Jason,
On 4/16/21 1:07 AM, Jason Gunthorpe wrote:
> On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
>> Hi Jason,
>>
>> On 4/1/21 6:03 PM, Jason Gunthorpe wrote:
>>> On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
>>>
DMA page faults are delivered to root-complex via
Hi Jason,
On Thu, 15 Apr 2021 20:07:32 -0300, Jason Gunthorpe wrote:
> On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
> > Hi Jason,
> >
> > On 4/1/21 6:03 PM, Jason Gunthorpe wrote:
> > > On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
> > >
> > >> DMA page faults
On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
> Hi Jason,
>
> On 4/1/21 6:03 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
> >
> >> DMA page faults are delivered to root-complex via page request message and
> >> it is per-device according
Hi Jason,
On 4/1/21 6:03 PM, Jason Gunthorpe wrote:
> On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
>
>> DMA page faults are delivered to root-complex via page request message and
>> it is per-device according to PCIe spec. Page request handling flow is:
>>
>> 1) iommu driver
On Wed, Apr 07, 2021 at 11:50:02PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, April 7, 2021 8:21 PM
> >
> > On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
> >
> > > > Because if you don't then we enter insane world where a PASID is being
> > > >
On Wed, Apr 07, 2021 at 04:36:54PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 07, 2021 at 08:43:50PM +0200, Jean-Philippe Brucker wrote:
>
> > * Get a container handle out of /dev/ioasid (or /dev/iommu, really.)
> > No operation available since we don't know what the device and IOMMU
> >
> From: Jason Gunthorpe
> Sent: Wednesday, April 7, 2021 8:21 PM
>
> On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
>
> > > Because if you don't then we enter insane world where a PASID is being
> > > created under /dev/ioasid but its translation path flows through setup
> > >
On Wed, Apr 07, 2021 at 08:43:50PM +0200, Jean-Philippe Brucker wrote:
> * Get a container handle out of /dev/ioasid (or /dev/iommu, really.)
> No operation available since we don't know what the device and IOMMU
> capabilities are.
>
> * Attach the handle to a VF. With VFIO that would be
>
On Wed, Apr 07, 2021 at 08:17:50AM +, Tian, Kevin wrote:
> btw this discussion was raised when discussing the I/O page fault handling
> process. Currently the IOMMU layer implements a per-device fault reporting
> mechanism, which requires VFIO to register a handler to receive all faults
> on
On Wed, Apr 07, 2021 at 02:08:33AM +, Tian, Kevin wrote:
> > Because if you don't then we enter insane world where a PASID is being
> > created under /dev/ioasid but its translation path flows through setup
> > done by VFIO and the whole user API becomes an incomprehensible mess.
> >
> > How
On Wed, Apr 07, 2021 at 08:17:50AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 8:43 PM
> >
> > On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
> >
> > > > VFIO and VDPA has no buisness having map/unmap interfaces once we
> > have
> > > >
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:43 PM
>
> On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
>
> > > VFIO and VDPA has no buisness having map/unmap interfaces once we
> have
> > > /dev/ioasid. That all belongs in the iosaid side.
> > >
> > > I know they have
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:21 PM
>
> On Tue, Apr 06, 2021 at 01:02:05AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, April 6, 2021 7:40 AM
> > >
> > > On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > > > From: Jason
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 8:35 PM
>
> On Tue, Apr 06, 2021 at 01:27:15AM +, Tian, Kevin wrote:
> >
> > and here is one example why using existing VFIO/VDPA interface makes
> > sense. say dev1 (w/ sva) and dev2 (w/o sva) are placed in a single VFIO
> > container.
在 2021/4/6 下午8:42, Jason Gunthorpe 写道:
On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
VFIO and VDPA has no buisness having map/unmap interfaces once we have
/dev/ioasid. That all belongs in the iosaid side.
I know they have those interfaces today, but that doesn't mean we have
On Tue, Apr 06, 2021 at 09:35:17AM +0800, Jason Wang wrote:
> > VFIO and VDPA has no buisness having map/unmap interfaces once we have
> > /dev/ioasid. That all belongs in the iosaid side.
> >
> > I know they have those interfaces today, but that doesn't mean we have
> > to keep using them for
On Tue, Apr 06, 2021 at 01:27:15AM +, Tian, Kevin wrote:
>
> and here is one example why using existing VFIO/VDPA interface makes
> sense. say dev1 (w/ sva) and dev2 (w/o sva) are placed in a single VFIO
> container.
Forget about SVA, it is an irrelevant detail of how a PASID is
On Tue, Apr 06, 2021 at 01:02:05AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 7:40 AM
> >
> > On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, April 1, 2021 9:47 PM
> > > >
> > > > On
On Tue, Apr 06, 2021 at 12:37:35AM +, Tian, Kevin wrote:
> With nested translation it is GVA->GPA->HPA. The kernel needs to
> fix fault related to GPA->HPA (managed by VFIO/VDPA) while
> handle_mm_fault only handles HVA->HPA. In this case, the 2nd-level
> page fault is expected to be
> From: Tian, Kevin
> Sent: Tuesday, April 6, 2021 9:02 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, April 6, 2021 7:40 AM
> >
> > On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, April 1, 2021 9:47 PM
> > > >
> > > > On
在 2021/4/6 上午7:42, Jason Gunthorpe 写道:
On Fri, Apr 02, 2021 at 08:22:28AM +, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Tuesday, March 30, 2021 9:29 PM
First, userspace may use ioasid in a non-SVA scenario where ioasid is
bound to specific security context (e.g. a control vq in
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:43 AM
>
> On Fri, Apr 02, 2021 at 08:22:28AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, March 30, 2021 9:29 PM
> > >
> > > >
> > > > First, userspace may use ioasid in a non-SVA scenario where ioasid is
> >
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:40 AM
>
> On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 1, 2021 9:47 PM
> > >
> > > On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > > > From: Jason
> From: Jason Gunthorpe
> Sent: Tuesday, April 6, 2021 7:35 AM
>
> On Fri, Apr 02, 2021 at 07:30:23AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Friday, April 2, 2021 12:04 AM
> > >
> > > On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
> > >
> > > > DMA page
On Fri, Apr 02, 2021 at 08:22:28AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 9:29 PM
> >
> > >
> > > First, userspace may use ioasid in a non-SVA scenario where ioasid is
> > > bound to specific security context (e.g. a control vq in vDPA) instead of
>
On Fri, Apr 02, 2021 at 07:58:02AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 9:47 PM
> >
> > On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, April 1, 2021 9:16 PM
> > > >
> > > > On Thu,
On Fri, Apr 02, 2021 at 07:30:23AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, April 2, 2021 12:04 AM
> >
> > On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
> >
> > > DMA page faults are delivered to root-complex via page request message
> > and
> > > it is
Hi Jason,
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 7:54 PM
>
> On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
>
> > After reading your reply in https://lore.kernel.org/linux-
> iommu/20210331123801.gd1463...@nvidia.com/#t
> > So you mean /dev/ioasid FD is per-VM
> From: Tian, Kevin
> Sent: Friday, April 2, 2021 3:58 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 9:47 PM
> >
> > On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, April 1, 2021 9:16 PM
> > > >
> > > > On Thu,
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 9:29 PM
>
> >
> > First, userspace may use ioasid in a non-SVA scenario where ioasid is
> > bound to specific security context (e.g. a control vq in vDPA) instead of
> > tying to mm. In this case there is no pgtable binding initiated from
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 9:47 PM
>
> On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 1, 2021 9:16 PM
> > >
> > > On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > > > From: Jason
> From: Jason Gunthorpe
> Sent: Friday, April 2, 2021 12:04 AM
>
> On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
>
> > DMA page faults are delivered to root-complex via page request message
> and
> > it is per-device according to PCIe spec. Page request handling flow is:
> >
> > 1)
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 7:47 PM
[...]
> I'm worried Intel views the only use of PASID in a guest is with
> ENQCMD, but that is not consistent with the industry. We need to see
> normal nested PASID support with assigned PCI VFs.
I'm not quire flow here. Intel also
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 9:43 PM
>
> On Thu, Apr 01, 2021 at 01:38:46PM +, Liu, Yi L wrote:
> > > From: Jean-Philippe Brucker
> > > Sent: Thursday, April 1, 2021 8:05 PM
> > [...]
> > >
> > > Also wondering about:
> > >
> > > * Querying IOMMU nesting
On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> After reading your reply in
> https://lore.kernel.org/linux-iommu/20210331123801.gd1463...@nvidia.com/#t
> So you mean /dev/ioasid FD is per-VM instead of per-ioasid, so above skeleton
> doesn't suit your idea.
You can do it one PASID
On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 9:16 PM
> >
> > On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, April 1, 2021 7:47 PM
> > > [...]
> > > > I'm
On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 7:47 PM
> [...]
> > I'm worried Intel views the only use of PASID in a guest is with
> > ENQCMD, but that is not consistent with the industry. We need to see
> > normal nested
On Thu, Apr 01, 2021 at 01:38:46PM +, Liu, Yi L wrote:
> > From: Jean-Philippe Brucker
> > Sent: Thursday, April 1, 2021 8:05 PM
> [...]
> >
> > Also wondering about:
> >
> > * Querying IOMMU nesting capabilities before binding page tables (which
> > page table formats are supported?). We
On Thu, Apr 01, 2021 at 02:05:00PM +0200, Jean-Philippe Brucker wrote:
> On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> > > - how about AMD and ARM's vSVA support? Their PASID allocation and page
> > > table
> > > happens within guest. They only need to bind the guest PASID table
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 9:16 PM
>
> On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 1, 2021 7:47 PM
> > [...]
> > > I'm worried Intel views the only use of PASID in a guest is with
> > > ENQCMD,
> From: Jean-Philippe Brucker
> Sent: Thursday, April 1, 2021 8:05 PM
[...]
>
> Also wondering about:
>
> * Querying IOMMU nesting capabilities before binding page tables (which
> page table formats are supported?). We were planning to have a VFIO cap,
> but I'm guessing we need to go back
Hi Jason,
On Wed, 31 Mar 2021 21:37:05 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 31, 2021 at 04:46:21PM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 31 Mar 2021 09:38:01 -0300, Jason Gunthorpe
> > wrote:
> > > > > Get rid of the ioasid set.
> > > > >
> > > > > Each driver has its
On Thu, Apr 01, 2021 at 10:23:55AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 31 Mar 2021 21:37:05 -0300, Jason Gunthorpe wrote:
>
> > On Wed, Mar 31, 2021 at 04:46:21PM -0700, Jacob Pan wrote:
> > > Hi Jason,
> > >
> > > On Wed, 31 Mar 2021 09:38:01 -0300, Jason Gunthorpe
> > > wrote:
On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
> DMA page faults are delivered to root-complex via page request message and
> it is per-device according to PCIe spec. Page request handling flow is:
>
> 1) iommu driver receives a page request from device
> 2) iommu driver parses the
On Thu, Apr 01, 2021 at 04:38:44AM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, March 31, 2021 8:41 PM
> >
> > On Wed, Mar 31, 2021 at 07:38:36AM +, Liu, Yi L wrote:
> >
> > > The reason is /dev/ioasid FD is per-VM since the ioasid allocated to
> > > the VM should
On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> > - how about AMD and ARM's vSVA support? Their PASID allocation and page
> > table
> > happens within guest. They only need to bind the guest PASID table to
> > host.
In this case each VM has its own IOASID space, and the host IOASID
Hi Jason,
> From: Liu, Yi L
> Sent: Thursday, April 1, 2021 12:39 PM
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, March 31, 2021 8:41 PM
> >
> > On Wed, Mar 31, 2021 at 07:38:36AM +, Liu, Yi L wrote:
> >
> > > The reason is /dev/ioasid FD is per-VM since the ioasid allocated to
> > >
> From: Jason Gunthorpe
> Sent: Wednesday, March 31, 2021 8:41 PM
>
> On Wed, Mar 31, 2021 at 07:38:36AM +, Liu, Yi L wrote:
>
> > The reason is /dev/ioasid FD is per-VM since the ioasid allocated to
> > the VM should be able to be shared by all assigned device for the VM.
> > But the SVA
On Wed, Mar 31, 2021 at 04:46:21PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 31 Mar 2021 09:38:01 -0300, Jason Gunthorpe wrote:
>
> > > > Get rid of the ioasid set.
> > > >
> > > > Each driver has its own list of allowed ioasids.
> > [...]
> >
> > The /dev/ioasid FD replaces this
Hi Jason,
On Wed, 31 Mar 2021 09:38:01 -0300, Jason Gunthorpe wrote:
> > > Get rid of the ioasid set.
> > >
> > > Each driver has its own list of allowed ioasids.
> [...]
>
> The /dev/ioasid FD replaces this security check. By becoming FD
> centric you don't need additional kernel
Hi Jason,
On Wed, 31 Mar 2021 15:33:24 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 31, 2021 at 11:20:30AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 31 Mar 2021 14:31:48 -0300, Jason Gunthorpe
> > wrote:
> > > > > We should try to avoid hidden behind the scenes kernel
> > > > >
On Wed, Mar 31, 2021 at 11:20:30AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 31 Mar 2021 14:31:48 -0300, Jason Gunthorpe wrote:
>
> > > > We should try to avoid hidden behind the scenes kernel
> > > > interconnections between subsystems.
> > > >
> > > Can we? in case of exception.
Hi Jason,
On Wed, 31 Mar 2021 14:31:48 -0300, Jason Gunthorpe wrote:
> > > We should try to avoid hidden behind the scenes kernel
> > > interconnections between subsystems.
> > >
> > Can we? in case of exception. Since all these IOCTLs are coming from the
> > unreliable user space, we must
On Wed, Mar 31, 2021 at 09:34:57AM -0700, Jacob Pan wrote:
> "3.3 PASID translation
> To support PASID isolation for Shared Work Queues used by VMs, the CPU must
> provide a way for the PASID to be communicated to the device in the DMWr
> transaction. On Intel CPUs, the CPU provides a PASID
Hi Jason,
On Wed, 31 Mar 2021 09:28:05 -0300, Jason Gunthorpe wrote:
> On Tue, Mar 30, 2021 at 05:10:41PM -0700, Jacob Pan wrote:
> [...]
> [...]
> [...]
> > This requires the mdev driver to obtain a list of allowed
> > PASIDs(possibly during PASID bind time) prior to do enforcement.
On Wed, Mar 31, 2021 at 07:38:36AM +, Liu, Yi L wrote:
> The reason is /dev/ioasid FD is per-VM since the ioasid allocated to
> the VM should be able to be shared by all assigned device for the VM.
> But the SVA operations (bind/unbind page table, cache_invalidate) should
> be per-device.
It
On Wed, Mar 31, 2021 at 07:41:40AM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 9:28 PM
> >
> > On Tue, Mar 30, 2021 at 04:14:58AM +, Tian, Kevin wrote:
> >
> > > One correction. The mdev should still construct the list of allowed
> > > PASID's
> > as
On Tue, Mar 30, 2021 at 05:10:41PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Tue, 30 Mar 2021 10:43:13 -0300, Jason Gunthorpe wrote:
>
> > > If two mdevs from the same PF dev are assigned to two VMs, the PASID
> > > table will be shared. IOASID set ensures one VM cannot program another
> > >
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 9:43 PM
[..]
> No, the mdev device driver must enforce this directly. It is the one
> that programms the physical shared HW, it is the one that needs a list
> of PASID's it is allowed to program *for each mdev*
>
> ioasid_set doesn't seem
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 9:28 PM
>
> On Tue, Mar 30, 2021 at 04:14:58AM +, Tian, Kevin wrote:
>
> > One correction. The mdev should still construct the list of allowed PASID's
> as
> > you said (by listening to IOASID_BIND/UNBIND event), in addition to the
>
Hi Jason,
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 9:29 PM
>
> On Tue, Mar 30, 2021 at 01:37:05AM +, Tian, Kevin wrote:
[...]
> > Hi, Jason,
> >
> > Actually above is a major open while we are refactoring vSVA uAPI toward
> > this direction. We have two concerns about merging
Hi Jason,
On Tue, 30 Mar 2021 10:43:13 -0300, Jason Gunthorpe wrote:
> > If two mdevs from the same PF dev are assigned to two VMs, the PASID
> > table will be shared. IOASID set ensures one VM cannot program another
> > VM's PASIDs. I assume 'secure context' is per VM when it comes to host
> >
On Tue, Mar 30, 2021 at 03:42:24PM +0200, Jean-Philippe Brucker wrote:
> On Tue, Mar 30, 2021 at 10:07:55AM -0300, Jason Gunthorpe wrote:
> > On Fri, Mar 26, 2021 at 09:06:42AM +0100, Jean-Philippe Brucker wrote:
> >
> > > It's not inconceivable to have a control queue doing DMA tagged with
> > >
On Mon, Mar 29, 2021 at 03:55:26PM -0700, Jacob Pan wrote:
> In one of the earlier discussions, I was made aware of some use cases (by
> AMD, iirc) where PASID can be used w/o IOMMU. That is why I tried to keep
> ioasid a separate subsystem. Other than that, I don't see an issue
> combining the
On Tue, Mar 30, 2021 at 10:07:55AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 26, 2021 at 09:06:42AM +0100, Jean-Philippe Brucker wrote:
>
> > It's not inconceivable to have a control queue doing DMA tagged with
> > PASID. The devices I know either use untagged DMA, or have a choice to use
> > a
On Tue, Mar 30, 2021 at 01:37:05AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 12:32 AM
> >
> > On Wed, Mar 24, 2021 at 12:05:28PM -0700, Jacob Pan wrote:
> >
> > > > IMHO a use created PASID is either bound to a mm (current) at creation
> > > > time,
On Tue, Mar 30, 2021 at 04:14:58AM +, Tian, Kevin wrote:
> One correction. The mdev should still construct the list of allowed PASID's as
> you said (by listening to IOASID_BIND/UNBIND event), in addition to the
> ioasid
> set maintained per VM (updated when a PASID is allocated/freed). The
On Tue, Mar 30, 2021 at 02:24:09AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 12:32 AM
> > > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host
> > > mm,
> > > the use case is as the following:
> >
> > From that doc:
> >
> > It
On Fri, Mar 26, 2021 at 09:06:42AM +0100, Jean-Philippe Brucker wrote:
> It's not inconceivable to have a control queue doing DMA tagged with
> PASID. The devices I know either use untagged DMA, or have a choice to use
> a PASID.
I don't think we should encourage that. A PASID and all the
> From: Tian, Kevin
> Sent: Tuesday, March 30, 2021 10:24 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 30, 2021 12:32 AM
> > > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host
> > > mm,
> > > the use case is as the following:
> >
> > From that doc:
> >
> > It
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 12:32 AM
> > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host mm,
> > the use case is as the following:
>
> From that doc:
>
> It is imperative to enforce
> VM-IOASID ownership such that a malicious guest cannot
> From: Jason Gunthorpe
> Sent: Tuesday, March 30, 2021 12:32 AM
>
> On Wed, Mar 24, 2021 at 12:05:28PM -0700, Jacob Pan wrote:
>
> > > IMHO a use created PASID is either bound to a mm (current) at creation
> > > time, or it will never be bound to a mm and its page table is under
> > > user
Hi Jason,
On Mon, 29 Mar 2021 13:31:47 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 24, 2021 at 12:05:28PM -0700, Jacob Pan wrote:
>
> > > IMHO a use created PASID is either bound to a mm (current) at creation
> > > time, or it will never be bound to a mm and its page table is under
> > > user
On Wed, Mar 24, 2021 at 12:05:28PM -0700, Jacob Pan wrote:
> > IMHO a use created PASID is either bound to a mm (current) at creation
> > time, or it will never be bound to a mm and its page table is under
> > user control via /dev/ioasid.
> >
> True for PASID used in native SVA bind. But for
On Thu, Mar 25, 2021 at 02:16:45PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 25, 2021 at 10:02:36AM -0700, Jacob Pan wrote:
> > Hi Jean-Philippe,
> >
> > On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
> > wrote:
> >
> > > On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
>
Hi Jason,
On Thu, 25 Mar 2021 14:16:45 -0300, Jason Gunthorpe wrote:
> On Thu, Mar 25, 2021 at 10:02:36AM -0700, Jacob Pan wrote:
> > Hi Jean-Philippe,
> >
> > On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
> > wrote:
> >
> > > On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan
On Thu, Mar 25, 2021 at 10:02:36AM -0700, Jacob Pan wrote:
> Hi Jean-Philippe,
>
> On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
> wrote:
>
> > On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> > > Hi Jason,
> > >
> > > On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe
Hi Jean-Philippe,
On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker
wrote:
> On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe
> > wrote:
> > > On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan
On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > And a flag IOMMU_SVA_BIND_SUPERVISOR (not that I plan to implement it in
> > the SMMU, but I think we need to clean the current usage)
> >
> You mean move #define SVM_FLAG_SUPERVISOR_MODE out of Intel code to be a
> generic flag in
On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe wrote:
>
> > On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > > > Also wondering about device driver allocating auxiliary domains for
> > > > their
Hi Jason,
On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > > Also wondering about device driver allocating auxiliary domains for
> > > their private use, to do iommu_map/unmap on private PASIDs (a clean
> > > replacement
Hi Jason,
On Mon, 22 Mar 2021 09:03:00 -0300, Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe
> > wrote:
> > > On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker
> > >
On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:
> > Also wondering about device driver allocating auxiliary domains for their
> > private use, to do iommu_map/unmap on private PASIDs (a clean replacement
> > to super SVA, for example). Would that go through the same path as
> >
Hi Jean-Philippe,
On Mon, 22 Mar 2021 10:24:00 +0100, Jean-Philippe Brucker
wrote:
> On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe
> > wrote:
> > > On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe
On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe wrote:
>
> > On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> > > On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> > > > On
On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe wrote:
>
> > On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> > > On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> > > > On
Hi Jason,
On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> > On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> > > On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
> > >
Hi Jean-Philippe,
On Fri, 19 Mar 2021 10:58:41 +0100, Jean-Philippe Brucker
wrote:
> > Slightly off the title. As we are moving to use cgroup to limit PASID
> > allocations, it would be much simpler if we enforce on the current
> > task.
>
> Yes I think we should do that. Is there a problem
On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker wrote:
> On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> > On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
> >
> > > Although there is no use for it at the moment (only two upstream users and
On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
>
> > Although there is no use for it at the moment (only two upstream users and
> > it looks like amdkfd always uses current too), I quite like the
> >
On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker wrote:
> Although there is no use for it at the moment (only two upstream users and
> it looks like amdkfd always uses current too), I quite like the
> client-server model where the privileged process does bind() and programs
> the
Hi Jacob,
On Thu, Mar 18, 2021 at 05:22:34PM -0700, Jacob Pan wrote:
> Hi Jean,
>
> Slightly off the title. As we are moving to use cgroup to limit PASID
> allocations, it would be much simpler if we enforce on the current task.
Yes I think we should do that. Is there a problem with charging
Hi Jean,
Slightly off the title. As we are moving to use cgroup to limit PASID
allocations, it would be much simpler if we enforce on the current task.
However, iommu_sva_alloc_pasid() takes an mm_struct pointer as argument
which implies it can be something other the the current task mm. So far
1 - 100 of 101 matches
Mail list logo
