On Fri, Sep 22, 2023 at 6:55 AM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > On Thu, Sep 21, 2023 at 04:45:45PM -0400, Michael S. Tsirkin wrote: > > On Thu, Sep 21, 2023 at 04:49:46PM -0300, Jason Gunthorpe wrote: > > > On Thu, Sep 21, 2023 at 03:13:10PM -0400, Michael S. Tsirkin wrote: > > > > On Thu, Sep 21, 2023 at 03:39:26PM -0300, Jason Gunthorpe wrote: > > > > > On Thu, Sep 21, 2023 at 12:53:04PM -0400, Michael S. Tsirkin wrote: > > > > > > > vdpa is not vfio, I don't know how you can suggest vdpa is a > > > > > > > replacement for a vfio driver. They are completely different > > > > > > > things. > > > > > > > Each side has its own strengths, and vfio especially is accelerating > > > > > > > in its capability in way that vpda is not. eg if an iommufd conversion > > > > > > > had been done by now for vdpa I might be more sympathetic. > > > > > > > > > > > > Yea, I agree iommufd is a big problem with vdpa right now. Cindy was > > > > > > sick and I didn't know and kept assuming she's working on this. I don't > > > > > > think it's a huge amount of work though. I'll take a look. > > > > > > Is there anything else though? Do tell. > > > > > > > > > > Confidential compute will never work with VDPA's approach. > > > > > > > > I don't see how what this patchset is doing is different > > > > wrt to Confidential compute - you trap IO accesses and emulate. > > > > Care to elaborate? > > > > > > This patch series isn't about confidential compute, you asked about > > > the future. VFIO will support confidential compute in the future, VDPA > > > will not. What blocks vDPA from supporting that? > > > > Nonsense it already works. > > That isn't what I'm talking about. With a real PCI function and TDISP > we can actually DMA directly from the guest's memory without needing > the ugly bounce buffer hack. Then you can get decent performance. This series requires the trapping in the legacy I/O BAR in VFIO. Why can TDISP work when trapping in VFIO but not vDPA? If neither, how can TDISP affect here? > > > But I did not ask about the future since I do not believe it > > can be confidently predicted. I asked what is missing in VDPA > > now for you to add this feature there and not in VFIO. > > I don't see that VDPA needs this, VDPA should process the IO BAR on > its own with its own logic, just like everything else it does. > > This is specifically about avoiding mediation by relaying directly the > IO BAR operations to the device itself. So we had: 1) a new virtio specific driver for VFIO 2) the existing vp_vdpa driver How much differences between them in the context of the mediation or relaying? Or is it hard to introduce admin commands in the vDPA bus? > That is the entire irony, this whole scheme was designed and > standardized *specifically* to avoid complex mediation and here you > are saying we should just use mediation. No, using "simple VFIO passthrough" is just fine. Thanks > > Jason >
