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
>
>
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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,
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
> >
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,
>
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
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
> 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
>
> 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
> > > > >
> 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
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,
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,
> 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,
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
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 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
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
> 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
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
53 matches
Mail list logo
