On Sun, Nov 24, 2019 at 10:51:24PM +0800, Tiwei Bie wrote: > > > You removed JasonW's other reply in above quote. He said it clearly > > > that we do want/need to assign parts of device BAR to the VM. > > > > Generally we don't look at patches based on stuff that isn't in them. > > The hardware is ready, and it's something really necessary (for > the performance). It was planned to be added immediately after > current series. If you want, it certainly can be included right now. I don't think it makes a significant difference, there are enough reasons already that this does not belong in vfio. Both Greg and I already were very against using mdev as an alterative to the driver core. > > > IIUC, your point is to suggest us invent new DMA API for userspace to > > > use instead of leveraging VFIO's well defined DMA API. Even if we don't > > > use VFIO at all, I would imagine it could be very VFIO-like (e.g. caps > > > for BAR + container/group for DMA) eventually. > > > > None of the other user dma subsystems seem to have the problems you > > are imagining here. Perhaps you should try it first? > > Actually VFIO DMA API wasn't used at the beginning of vhost-mdev. But > after the discussion in upstream during the RFC stage since the last > year, the conclusion is that leveraging VFIO's existing DMA API would > be the better choice and then vhost-mdev switched to that direction. Well, unfortunately, I think that discussion may have led you wrong. Do you have a link? Did you post an ICF driver that didn't use vfio? Jason
