Re: (proposal) RE: [PATCH v7 00/16] vfio: expose virtual Shared Virtual Addressing to VMs

[Jason Wang <jasowang@redhat.com>]

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


>