On Tue, Nov 03, 2020 at 08:14:29PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 01:48:51PM -0400, Jason Gunthorpe wrote:
> > I think the same PCI driver with a small flag to support the PF or
> > VF is not the same as two completely different drivers in different
> > subsystems
>
> Ther
On Tue, Nov 03, 2020 at 01:48:51PM -0400, Jason Gunthorpe wrote:
> I think the same PCI driver with a small flag to support the PF or
> VF is not the same as two completely different drivers in different
> subsystems
There are counter-examples: ixgbe vs. ixgbevf.
Note that also a single driver ca
On Tue, Nov 03, 2020 at 05:55:40PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 11:22:23AM -0400, Jason Gunthorpe wrote:
> > This whole thread was brought up by IDXD which has a SVA driver and
> > now wants to add a vfio-mdev driver too. SVA devices that want to be
> > plugged into VMs a
On Tue, Nov 03, 2020 at 11:22:23AM -0400, Jason Gunthorpe wrote:
> This whole thread was brought up by IDXD which has a SVA driver and
> now wants to add a vfio-mdev driver too. SVA devices that want to be
> plugged into VMs are going to be common - this architecture that a SVA
> driver cannot cove
On Tue, Nov 03, 2020 at 03:35:32PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 10:06:42AM -0400, Jason Gunthorpe wrote:
> > The point is that other places beyond VFIO need this
>
> Which and why?
>
> > Sure, but sometimes it is necessary, and in those cases the answer
> > can't be "rew
On Tue, Nov 03, 2020 at 10:06:42AM -0400, Jason Gunthorpe wrote:
> The point is that other places beyond VFIO need this
Which and why?
> Sure, but sometimes it is necessary, and in those cases the answer
> can't be "rewrite a SVA driver to use vfio"
This is getting to abstract. Can you come up w
On Tue, Nov 03, 2020 at 03:03:18PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 09:23:35AM -0400, Jason Gunthorpe wrote:
> > Userspace needs fine grained control over the composition of the page
> > table behind the PASID, 1:1 with the mm_struct is only one use case.
>
> VFIO already of
On Tue, Nov 03, 2020 at 09:23:35AM -0400, Jason Gunthorpe wrote:
> Userspace needs fine grained control over the composition of the page
> table behind the PASID, 1:1 with the mm_struct is only one use case.
VFIO already offers an interface for that. It shouldn't be too
complicated to expand that
On Tue, Nov 03, 2020 at 02:18:52PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 08:56:43AM -0400, Jason Gunthorpe wrote:
> > On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> > > So having said this, what is the benefit of exposing those SVA internals
> > > to user-space
On Tue, Nov 03, 2020 at 08:56:43AM -0400, Jason Gunthorpe wrote:
> On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> > So having said this, what is the benefit of exposing those SVA internals
> > to user-space?
>
> Only the device use of the PASID is device specific, the actual PA
On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> So having said this, what is the benefit of exposing those SVA internals
> to user-space?
Only the device use of the PASID is device specific, the actual PASID
and everything on the IOMMU side is generic.
There is enough API there
On Mon, Oct 12, 2020 at 08:38:54AM +, Tian, Kevin wrote:
> > From: Jason Wang
> > Jason suggest something like /dev/sva. There will be a lot of other
> > subsystems that could benefit from this (e.g vDPA).
Honestly, I fail to see the benefit of offloading these IOMMU specific
setup tasks to
On 2020/10/22 上午11:54, Liu, Yi L wrote:
Hi Jason,
From: Jason Wang
Sent: Thursday, October 22, 2020 10:56 AM
[...]
If you(Intel) don't have plan to do vDPA, you should not prevent other vendors
from implementing PASID capable hardware through non-VFIO subsystem/uAPI
on top of your SIOV arc
Hi Jason,
> From: Jason Wang
> Sent: Thursday, October 22, 2020 10:56 AM
>
[...]
> If you(Intel) don't have plan to do vDPA, you should not prevent other vendors
> from implementing PASID capable hardware through non-VFIO subsystem/uAPI
> on top of your SIOV architecture. Isn't it?
yes, that's
On 2020/10/22 上午1:51, Raj, Ashok wrote:
On Wed, Oct 21, 2020 at 08:48:29AM -0300, Jason Gunthorpe wrote:
On Tue, Oct 20, 2020 at 01:27:13PM -0700, Raj, Ashok wrote:
On Tue, Oct 20, 2020 at 05:14:03PM -0300, Jason Gunthorpe wrote:
On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote:
On
On Wed, Oct 21, 2020 at 08:32:18PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 21, 2020 at 01:03:15PM -0700, Raj, Ashok wrote:
>
> > I'm not sure why you tie in IDXD and VDPA here. How IDXD uses native
> > SVM is orthogonal to how we achieve mdev passthrough to guest and
> > vSVM.
>
> Everyone as
On Wed, Oct 21, 2020 at 01:03:15PM -0700, Raj, Ashok wrote:
> I'm not sure why you tie in IDXD and VDPA here. How IDXD uses native
> SVM is orthogonal to how we achieve mdev passthrough to guest and
> vSVM.
Everyone assumes that vIOMMU and SIOV aka PASID is going to be needed
on the VDPA side as
On Wed, Oct 21, 2020 at 03:24:42PM -0300, Jason Gunthorpe wrote:
>
> > Contrary to your argument, vDPA went with a half blown device only
> > iommu user without considering existing abstractions like containers
>
> VDPA IOMMU was done *for Intel*, as the kind of half-architected thing
> you are
On Wed, Oct 21, 2020 at 08:48:29AM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 20, 2020 at 01:27:13PM -0700, Raj, Ashok wrote:
> > On Tue, Oct 20, 2020 at 05:14:03PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote:
> > > > On Tue, Oct 20, 2020 at 04:55
On Wed, Oct 21, 2020 at 10:51:46AM -0700, Raj, Ashok wrote:
> > If they didn't plan to use it, bit of a strawman argument, right?
>
> This doesn't need to continue like the debates :-) Pun intended :-)
>
> I don't think it makes any sense to have an abstract strawman argument
> design discussion
On Tue, Oct 20, 2020 at 01:27:13PM -0700, Raj, Ashok wrote:
> On Tue, Oct 20, 2020 at 05:14:03PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote:
> > > On Tue, Oct 20, 2020 at 04:55:57PM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Oct 20, 2020 at 12:51
On 2020/10/20 下午10:19, Liu, Yi L wrote:
From: Jason Gunthorpe
Sent: Tuesday, October 20, 2020 10:02 PM
[...]
Whoever provides the vIOMMU emulation and relays the page fault to the
guest
has to translate the RID -
that's the point. But the device info (especially the sub-device info) is
wit
On Tue, Oct 20, 2020 at 05:14:03PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote:
> > On Tue, Oct 20, 2020 at 04:55:57PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 20, 2020 at 12:51:46PM -0700, Raj, Ashok wrote:
> > > > I think we agreed (or agree t
On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote:
> On Tue, Oct 20, 2020 at 04:55:57PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 20, 2020 at 12:51:46PM -0700, Raj, Ashok wrote:
> > > I think we agreed (or agree to disagree and commit) for device types that
> > > we have for SIOV, VFI
On Tue, Oct 20, 2020 at 04:55:57PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 20, 2020 at 12:51:46PM -0700, Raj, Ashok wrote:
> > I think we agreed (or agree to disagree and commit) for device types that
> > we have for SIOV, VFIO based approach works well without having to
> > re-invent
> > an
On Tue, Oct 20, 2020 at 12:51:46PM -0700, Raj, Ashok wrote:
> I think we agreed (or agree to disagree and commit) for device types that
> we have for SIOV, VFIO based approach works well without having to re-invent
> another way to do the same things. Not looking for a shortcut by any means,
> b
On Tue, Oct 20, 2020 at 02:03:36PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 20, 2020 at 09:24:30AM -0700, Raj, Ashok wrote:
> > Hi Jason,
> >
> >
> > On Tue, Oct 20, 2020 at 11:02:17AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 20, 2020 at 10:21:41AM +, Liu, Yi L wrote:
> > >
> > > >
On Tue, Oct 20, 2020 at 09:24:30AM -0700, Raj, Ashok wrote:
> Hi Jason,
>
>
> On Tue, Oct 20, 2020 at 11:02:17AM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 20, 2020 at 10:21:41AM +, Liu, Yi L wrote:
> >
> > > > I'm sure there will be some
> > > > weird overlaps because we can't delete any
Hi Jason,
On Tue, Oct 20, 2020 at 11:02:17AM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 20, 2020 at 10:21:41AM +, Liu, Yi L wrote:
>
> > > I'm sure there will be some
> > > weird overlaps because we can't delete any of the existing VFIO APIs, but
> > > that
> > > should not be a blocker.
>
> From: Jason Gunthorpe
> Sent: Tuesday, October 20, 2020 10:02 PM
[...]
> > > Whoever provides the vIOMMU emulation and relays the page fault to the
> guest
> > > has to translate the RID -
> >
> > that's the point. But the device info (especially the sub-device info) is
> > within the passthru f
> From: Jason Gunthorpe
> Sent: Tuesday, October 20, 2020 10:05 PM
> To: Liu, Yi L
>
> On Tue, Oct 20, 2020 at 02:00:31PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, October 20, 2020 9:55 PM
> > >
> > > On Tue, Oct 20, 2020 at 09:40:14AM +, Liu, Yi L wrote:
> >
On Tue, Oct 20, 2020 at 02:00:31PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, October 20, 2020 9:55 PM
> >
> > On Tue, Oct 20, 2020 at 09:40:14AM +, Liu, Yi L wrote:
> >
> > > > See previous discussion with Kevin. If I understand correctly, you
> > > > expect a
> >
On Tue, Oct 20, 2020 at 10:21:41AM +, Liu, Yi L wrote:
> > I'm sure there will be some
> > weird overlaps because we can't delete any of the existing VFIO APIs, but
> > that
> > should not be a blocker.
>
> but the weird thing is what we should consider. And it perhaps not just
> overlap, it
> From: Jason Gunthorpe
> Sent: Tuesday, October 20, 2020 9:55 PM
>
> On Tue, Oct 20, 2020 at 09:40:14AM +, Liu, Yi L wrote:
>
> > > See previous discussion with Kevin. If I understand correctly, you expect
> > > a
> shared
> > > L2 table if vDPA and VFIO device are using the same PASID.
>
On Tue, Oct 20, 2020 at 09:40:14AM +, Liu, Yi L wrote:
> > See previous discussion with Kevin. If I understand correctly, you expect a
> > shared
> > L2 table if vDPA and VFIO device are using the same PASID.
>
> L2 table sharing is not mandatory. The mapping is the same, but no need to
> as
> From: Jason Gunthorpe
> Sent: Monday, October 19, 2020 10:25 PM
>
> On Mon, Oct 19, 2020 at 08:39:03AM +, Liu, Yi L wrote:
> > Hi Jason,
> >
> > Good to see your response.
>
> Ah, I was away
got it. :-)
> > > > > Second, IOMMU nested translation is a per IOMMU domain
> > > > > capability
> From: Jason Wang
> Sent: Tuesday, October 20, 2020 5:20 PM
>
> Hi Yi:
>
> On 2020/10/20 ??4:19, Liu, Yi L wrote:
> >> Yes, but since PASID is a global identifier now, I think kernel
> >> should track the a device list per PASID?
> > We have such track. It's done in iommu driver. You can refer
Hi Yi:
On 2020/10/20 下午4:19, Liu, Yi L wrote:
Yes, but since PASID is a global identifier now, I think kernel should
track the a device list per PASID?
We have such track. It's done in iommu driver. You can refer to the
struct intel_svm. PASID is a global identifier, but it doesn’t affect that
Hey Jason,
> From: Jason Wang
> Sent: Tuesday, October 20, 2020 2:18 PM
>
> On 2020/10/15 ??6:14, Liu, Yi L wrote:
> >> From: Jason Wang
> >> Sent: Thursday, October 15, 2020 4:41 PM
> >>
> >>
> >> On 2020/10/15 ??3:58, Tian, Kevin wrote:
> From: Jason Wang
> Sent: Thursday, October
On 2020/10/15 下午6:14, Liu, Yi L wrote:
From: Jason Wang
Sent: Thursday, October 15, 2020 4:41 PM
On 2020/10/15 ??3:58, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, October 15, 2020 2:52 PM
On 2020/10/14 ??11:08, Tian, Kevin wrote:
From: Jason Wang
Sent: Tuesday, October 13, 2020
On Mon, Oct 19, 2020 at 08:39:03AM +, Liu, Yi L wrote:
> Hi Jason,
>
> Good to see your response.
Ah, I was away
> > > > Second, IOMMU nested translation is a per IOMMU domain
> > > > capability. Since IOMMU domains are managed by VFIO/VDPA
> > > > (alloc/free domain, attach/detach device,
Hi Jason,
Good to see your response.
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 11:37 PM
>
> On Wed, Oct 14, 2020 at 03:16:22AM +, Tian, Kevin wrote:
> > Hi, Alex and Jason (G),
> >
> > How about your opinion for this new proposal? For now looks both
> > Jason (W) and Jean are
On Wed, Oct 14, 2020 at 03:16:22AM +, Tian, Kevin wrote:
> Hi, Alex and Jason (G),
>
> How about your opinion for this new proposal? For now looks both
> Jason (W) and Jean are OK with this direction and more discussions
> are possibly required for the new /dev/ioasid interface. Internally
>
> From: Jason Wang
> Sent: Thursday, October 15, 2020 4:41 PM
>
>
> On 2020/10/15 ??3:58, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Thursday, October 15, 2020 2:52 PM
> >>
> >>
> >> On 2020/10/14 ??11:08, Tian, Kevin wrote:
> From: Jason Wang
> Sent: Tuesday, October 13, 20
On 2020/10/15 下午3:58, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, October 15, 2020 2:52 PM
On 2020/10/14 上午11:08, Tian, Kevin wrote:
From: Jason Wang
Sent: Tuesday, October 13, 2020 2:22 PM
On 2020/10/12 下午4:38, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 202
> From: Jason Wang
> Sent: Thursday, October 15, 2020 2:52 PM
>
>
> On 2020/10/14 上午11:08, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Tuesday, October 13, 2020 2:22 PM
> >>
> >>
> >> On 2020/10/12 下午4:38, Tian, Kevin wrote:
> From: Jason Wang
> Sent: Monday, September 14, 20
On 2020/10/15 上午7:10, Alex Williamson wrote:
On Wed, 14 Oct 2020 03:08:31 +
"Tian, Kevin" wrote:
From: Jason Wang
Sent: Tuesday, October 13, 2020 2:22 PM
On 2020/10/12 下午4:38, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 2020 12:20 PM
[...]
> If it's possibl
On 2020/10/14 上午11:08, Tian, Kevin wrote:
From: Jason Wang
Sent: Tuesday, October 13, 2020 2:22 PM
On 2020/10/12 下午4:38, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 2020 12:20 PM
[...]
> If it's possible, I would suggest a generic uAPI instead of a VFIO
specific on
On Wed, 14 Oct 2020 03:08:31 +
"Tian, Kevin" wrote:
> > From: Jason Wang
> > Sent: Tuesday, October 13, 2020 2:22 PM
> >
> >
> > On 2020/10/12 下午4:38, Tian, Kevin wrote:
> > >> From: Jason Wang
> > >> Sent: Monday, September 14, 2020 12:20 PM
> > >>
> > > [...]
> > > > If it's pos
Hi, Alex and Jason (G),
How about your opinion for this new proposal? For now looks both
Jason (W) and Jean are OK with this direction and more discussions
are possibly required for the new /dev/ioasid interface. Internally
we're doing a quick prototype to see any unforeseen issue with this
separ
> From: Jason Wang
> Sent: Tuesday, October 13, 2020 2:22 PM
>
>
> On 2020/10/12 下午4:38, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Monday, September 14, 2020 12:20 PM
> >>
> > [...]
> > > If it's possible, I would suggest a generic uAPI instead of a VFIO
> >> specific one.
> >>
> >>
> From: Jean-Philippe Brucker
> Sent: Tuesday, October 13, 2020 6:28 PM
>
> On Mon, Oct 12, 2020 at 08:38:54AM +, Tian, Kevin wrote:
> > > From: Jason Wang
> > > Sent: Monday, September 14, 2020 12:20 PM
> > >
> > [...]
> > > If it's possible, I would suggest a generic uAPI instead of a VFI
On Mon, Oct 12, 2020 at 08:38:54AM +, Tian, Kevin wrote:
> > From: Jason Wang
> > Sent: Monday, September 14, 2020 12:20 PM
> >
> [...]
> > If it's possible, I would suggest a generic uAPI instead of a VFIO
> > specific one.
> >
> > Jason suggest something like /dev/sva. There will be a lot
On 2020/10/12 下午4:38, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 2020 12:20 PM
[...]
> If it's possible, I would suggest a generic uAPI instead of a VFIO
specific one.
Jason suggest something like /dev/sva. There will be a lot of other
subsystems that could benefit fr
> From: Jason Wang
> Sent: Monday, September 14, 2020 12:20 PM
>
[...]
> If it's possible, I would suggest a generic uAPI instead of a VFIO
> specific one.
>
> Jason suggest something like /dev/sva. There will be a lot of other
> subsystems that could benefit from this (e.g vDPA).
>
> Have you
On 2020/9/18 上午2:17, Jacob Pan (Jun) wrote:
Hi Jason,
On Thu, 17 Sep 2020 11:53:49 +0800, Jason Wang
wrote:
On 2020/9/17 上午7:09, Jacob Pan (Jun) wrote:
Hi Jason,
On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe
wrote:
On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
Hi Jason,
On Thu, 17 Sep 2020 11:53:49 +0800, Jason Wang
wrote:
> On 2020/9/17 上午7:09, Jacob Pan (Jun) wrote:
> > Hi Jason,
> > On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe
> > wrote:
> >
> >> On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
> >>> Hi Jason,
> >>> On We
On Thu, Sep 17, 2020 at 11:53:49AM +0800, Jason Wang wrote:
> > > When VDPA is used by qemu it makes sense that the PASID will be an
> > > arbitary IOVA map constructed to be 1:1 with the guest vCPU physical
> > > map. /dev/sva allows a single uAPI to do this kind of setup, and qemu
> > > can suppo
> From: Jason Gunthorpe
> Sent: Wednesday, September 16, 2020 10:45 PM
>
> On Wed, Sep 16, 2020 at 01:19:18AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, September 15, 2020 10:29 PM
> > >
> > > > Do they need a device at all? It's not clear to me why RID based
> >
On 2020/9/17 上午7:09, Jacob Pan (Jun) wrote:
Hi Jason,
On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe
wrote:
On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
Hi Jason,
On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe
wrote:
On Wed, Sep 16, 2020 at 09:33:43AM -070
Hi Jason,
On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe
wrote:
> On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
> > Hi Jason,
> > On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe
> > wrote:
> >
> > > On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote:
> >
On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
> Hi Jason,
> On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe
> wrote:
>
> > On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote:
> > > On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Se
Hi Jason,
On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe
wrote:
> On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote:
> > On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote:
> > > > > If user spac
On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote:
> On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote:
> > > > If user space wants to bind page tables, create the PASID with
> > > > /dev/sva, use ioctls the
Hi,
On 9/16/20 6:32 PM, Jason Gunthorpe wrote:
> On Wed, Sep 16, 2020 at 06:20:52PM +0200, Jean-Philippe Brucker wrote:
>> On Wed, Sep 16, 2020 at 11:51:48AM -0300, Jason Gunthorpe wrote:
>>> On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote:
And this is the only PASID mode
On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote:
> > > If user space wants to bind page tables, create the PASID with
> > > /dev/sva, use ioctls there to setup the page table the way it wants,
> > > then pass the now
On Wed, Sep 16, 2020 at 06:20:52PM +0200, Jean-Philippe Brucker wrote:
> On Wed, Sep 16, 2020 at 11:51:48AM -0300, Jason Gunthorpe wrote:
> > On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote:
> > > And this is the only PASID model for Arm SMMU (and AMD IOMMU, I believe):
> > >
On Wed, Sep 16, 2020 at 11:51:48AM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote:
> > And this is the only PASID model for Arm SMMU (and AMD IOMMU, I believe):
> > the PASID space of a PCI function cannot be shared between host and guest,
> >
On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote:
> > If user space wants to bind page tables, create the PASID with
> > /dev/sva, use ioctls there to setup the page table the way it wants,
> > then pass the now configured PASID to a driver that can use it.
>
> Are we talking about
On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote:
> And this is the only PASID model for Arm SMMU (and AMD IOMMU, I believe):
> the PASID space of a PCI function cannot be shared between host and guest,
> so we assign the whole PASID table along with the RID. Since we need the
On Wed, Sep 16, 2020 at 01:19:18AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, September 15, 2020 10:29 PM
> >
> > > Do they need a device at all? It's not clear to me why RID based
> > > IOMMU management fits within vfio's scope, but PASID based does not.
> >
> > In R
On Wed, Sep 16, 2020 at 01:19:18AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, September 15, 2020 10:29 PM
> >
> > > Do they need a device at all? It's not clear to me why RID based
> > > IOMMU management fits within vfio's scope, but PASID based does not.
> >
> > In R
On 2020/9/16 上午3:26, Raj, Ashok wrote:
IIUC, you are asking that part of the interface to move to a API interface
that potentially the new /dev/sva and VFIO could share? I think the API's
for PASID management themselves are generic (Jean's patchset + Jacob's
ioasid set management).
Yes, the in
On 2020/9/14 下午9:31, Jean-Philippe Brucker wrote:
If it's possible, I would suggest a generic uAPI instead of a VFIO specific
one.
A large part of this work is already generic uAPI, in
include/uapi/linux/iommu.h.
This is not what I read from this series, all the following uAPI is VFIO
speci
On 9/16/20 8:22 AM, Jacob Pan (Jun) wrote:
If user space wants to bind page tables, create the PASID with
/dev/sva, use ioctls there to setup the page table the way it wants,
then pass the now configured PASID to a driver that can use it.
Are we talking about bare metal SVA? If so, I don't see
> From: Jason Gunthorpe
> Sent: Tuesday, September 15, 2020 10:29 PM
>
> > Do they need a device at all? It's not clear to me why RID based
> > IOMMU management fits within vfio's scope, but PASID based does not.
>
> In RID mode vfio-pci completely owns the PCI function, so it is more
> natural
Hi Jason,
On Tue, 15 Sep 2020 20:51:26 -0300, Jason Gunthorpe
wrote:
> On Tue, Sep 15, 2020 at 03:08:51PM -0700, Jacob Pan wrote:
> > > A PASID vIOMMU solution sharable with VDPA and VFIO, based on a
> > > PASID control char dev (eg /dev/sva, or maybe /dev/iommu) seems
> > > like a reasonable sta
On Tue, Sep 15, 2020 at 03:08:51PM -0700, Jacob Pan wrote:
> > A PASID vIOMMU solution sharable with VDPA and VFIO, based on a PASID
> > control char dev (eg /dev/sva, or maybe /dev/iommu) seems like a
> > reasonable starting point for discussion.
>
> I am not sure what can really be consolidated
On Tue, Sep 15, 2020 at 12:26:32PM -0700, Raj, Ashok wrote:
> > Yes, there is. There is a limited pool of HW PASID's. If one user fork
> > bombs it can easially claim an unreasonable number from that pool as
> > each process will claim a PASID. That can DOS the rest of the system.
>
> Not sure ho
Hi Jason,
On Tue, 15 Sep 2020 15:45:10 -0300, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2020 at 11:11:54AM -0700, Raj, Ashok wrote:
> > > PASID applies widely to many device and needs to be introduced with a
> > > wide community agreement so all scenarios will be supportable.
> >
> > True, rea
On Tue, Sep 15, 2020 at 03:45:10PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 15, 2020 at 11:11:54AM -0700, Raj, Ashok wrote:
> > > PASID applies widely to many device and needs to be introduced with a
> > > wide community agreement so all scenarios will be supportable.
> >
> > True, reading some
On Tue, Sep 15, 2020 at 11:11:54AM -0700, Raj, Ashok wrote:
> > PASID applies widely to many device and needs to be introduced with a
> > wide community agreement so all scenarios will be supportable.
>
> True, reading some of the earlier replies I was clearly confused as I
> thought you were talk
On Tue, Sep 15, 2020 at 08:33:41AM -0300, Jason Gunthorpe wrote:
> On Mon, Sep 14, 2020 at 03:44:38PM -0700, Raj, Ashok wrote:
> > Hi Jason,
> >
> > I thought we discussed this at LPC, but still seems to be going in
> > circles :-(.
>
> We discused mdev at LPC, not PASID.
>
> PASID applies widel
On Mon, Sep 14, 2020 at 04:33:10PM -0600, Alex Williamson wrote:
> Can you explain that further, or spit-ball what you think this /dev/sva
> interface looks like and how a user might interact between vfio and
> this new interface?
When you open it you get some container, inside the container the
On Mon, Sep 14, 2020 at 03:44:38PM -0700, Raj, Ashok wrote:
> Hi Jason,
>
> I thought we discussed this at LPC, but still seems to be going in
> circles :-(.
We discused mdev at LPC, not PASID.
PASID applies widely to many device and needs to be introduced with a
wide community agreement so all
Hi Jason,
I thought we discussed this at LPC, but still seems to be going in
circles :-(.
On Mon, Sep 14, 2020 at 04:00:57PM -0300, Jason Gunthorpe wrote:
> On Mon, Sep 14, 2020 at 12:23:28PM -0600, Alex Williamson wrote:
> > On Mon, 14 Sep 2020 14:41:21 -0300
> > Jason Gunthorpe wrote:
> >
>
On Mon, 14 Sep 2020 16:00:57 -0300
Jason Gunthorpe wrote:
> On Mon, Sep 14, 2020 at 12:23:28PM -0600, Alex Williamson wrote:
> > On Mon, 14 Sep 2020 14:41:21 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Sep 14, 2020 at 10:58:57AM -0600, Alex Williamson wrote:
> > >
> > > > "its own
On Mon, Sep 14, 2020 at 12:23:28PM -0600, Alex Williamson wrote:
> On Mon, 14 Sep 2020 14:41:21 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Sep 14, 2020 at 10:58:57AM -0600, Alex Williamson wrote:
> >
> > > "its own special way" is arguable, VFIO is just making use of what's
> > > being propos
On Mon, 14 Sep 2020 14:41:21 -0300
Jason Gunthorpe wrote:
> On Mon, Sep 14, 2020 at 10:58:57AM -0600, Alex Williamson wrote:
>
> > "its own special way" is arguable, VFIO is just making use of what's
> > being proposed as the uapi via its existing IOMMU interface.
>
> I mean, if we have a /d
On Mon, Sep 14, 2020 at 10:58:57AM -0600, Alex Williamson wrote:
> "its own special way" is arguable, VFIO is just making use of what's
> being proposed as the uapi via its existing IOMMU interface.
I mean, if we have a /dev/sva then it makes no sense to extend the
VFIO interfaces with the same
On Mon, 14 Sep 2020 13:33:54 -0300
Jason Gunthorpe wrote:
> On Mon, Sep 14, 2020 at 09:22:47AM -0700, Raj, Ashok wrote:
> > Hi Jason,
> >
> > On Mon, Sep 14, 2020 at 10:47:38AM -0300, Jason Gunthorpe wrote:
> > > On Mon, Sep 14, 2020 at 03:31:13PM +0200, Jean-Philippe Brucker wrote:
> > >
>
On Mon, Sep 14, 2020 at 09:22:47AM -0700, Raj, Ashok wrote:
> Hi Jason,
>
> On Mon, Sep 14, 2020 at 10:47:38AM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 14, 2020 at 03:31:13PM +0200, Jean-Philippe Brucker wrote:
> >
> > > > Jason suggest something like /dev/sva. There will be a lot of other
>
Hi Jason,
On Mon, Sep 14, 2020 at 10:47:38AM -0300, Jason Gunthorpe wrote:
> On Mon, Sep 14, 2020 at 03:31:13PM +0200, Jean-Philippe Brucker wrote:
>
> > > Jason suggest something like /dev/sva. There will be a lot of other
> > > subsystems that could benefit from this (e.g vDPA).
> >
> > Do you
On Mon, Sep 14, 2020 at 03:31:13PM +0200, Jean-Philippe Brucker wrote:
> > Jason suggest something like /dev/sva. There will be a lot of other
> > subsystems that could benefit from this (e.g vDPA).
>
> Do you have a more precise idea of the interface /dev/sva would provide,
> how it would intera
On Mon, Sep 14, 2020 at 12:20:10PM +0800, Jason Wang wrote:
>
> On 2020/9/10 下午6:45, Liu Yi L wrote:
> > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> > Intel platforms allows address space sharing between device DMA and
> > applications. SVA can reduce programming compl
On Mon, Sep 14, 2020 at 10:38:10AM +, Tian, Kevin wrote:
> is widely used thus can better help verify the core logic with
> many existing devices. For vSVA, vDPA support has not be started
> while VFIO support is close to be accepted. It doesn't make much
> sense by blocking the VFIO part unti
> From: Jason Wang
> Sent: Monday, September 14, 2020 4:57 PM
>
> On 2020/9/14 下午4:01, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Monday, September 14, 2020 12:20 PM
> >>
> >> On 2020/9/10 下午6:45, Liu Yi L wrote:
> >>> Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) o
On 2020/9/14 下午4:01, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 2020 12:20 PM
On 2020/9/10 下午6:45, Liu Yi L wrote:
Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
Intel platforms allows address space sharing between device DMA and
applications. SVA
> From: Jason Wang
> Sent: Monday, September 14, 2020 12:20 PM
>
> On 2020/9/10 下午6:45, Liu Yi L wrote:
> > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> > Intel platforms allows address space sharing between device DMA and
> > applications. SVA can reduce programming c
On 2020/9/10 下午6:45, Liu Yi L wrote:
Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
Intel platforms allows address space sharing between device DMA and
applications. SVA can reduce programming complexity and enhance security.
This VFIO series is intended to expose SVA us
100 matches
Mail list logo
