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 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
another way to do the same things. Not looking for a shortcut by any means,
but we need to plan around existing hardware though. Looks like vDPA took
some shortcuts then to not abstract iommu uAPI instead :-)? When all
necessary hardware was available.. This would be a solved puzzle.
I think it is the opposite, vIOMMU and related has outgrown VFIO as
the "home" and needs to stand alone.
Apparently the HW that will need PASID for vDPA is Intel HW, so if
So just to make this clear, I did check internally if there are any plans
for vDPA + SVM. There are none at the moment.
Not SVM, SIOV.
... And that included.. I should have said vDPA + PASID, No current plans.
I have no idea who set expectations with you. Can you please put me in touch
with that person, privately is fine.
It was the team that aruged VDPA had to be done through VFIO - SIOV
and PASID was one of their reasons it had to be VFIO, check the list
archives
Humm... I could search the arhives, but the point is I'm confirming that
there is no forward looking plan!
And who ever did was it was based on probably strawman hypothetical argument that wasn't
grounded in reality.
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. Yi is looking into for pasid management alone. Rest
of the IOMMU related topics should wait until we have another
*real* use requiring consolidation.
Contrary to your argument, vDPA went with a half blown device only
iommu user without considering existing abstractions like containers
and such in VFIO is part of the reason the gap is big at the moment.
And you might not agree, but that's beside the point.
Can you explain why it must care VFIO abstractions? vDPA is trying to
hide device details which is fundamentally different with what VFIO
wants to do. vDPA allows the parent to deal with IOMMU stuffs, and if
necessary, the parent can talk with IOMMU drivers directly via IOMMU APIs.
Rather than pivot ourselves around hypothetical, strawman,
non-intersecting, suggesting architecture without having done a proof of
concept to validate the proposal should stop. We have to ground ourselves
in reality.
The reality is VFIO should not be the only user for (v)SVA/SIOV/PASID.
The kernel hard already had users like GPU or uacce.
The use cases we have so far for SIOV, VFIO and mdev seem to be the right
candidates and addresses them well. Now you might disagree, but as noted we
all agreed to move past this.
The mdev is not perfect for sure, but it's another topic.
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?
So if Intel has the willing to collaborate on the POC, I'd happy to
help. E.g it's not hard to have a PASID capable virtio device through
qemu, and we can start from there.
Thanks
