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 +0000, 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 may be a re-definition of VFIO container. As I mentioned, VFIO > > > container is IOMMU context from the day it was defined. It could be the > > > blocker. :-( > > > > So maybe you have to broaden the VFIO container to be usable by other > > subsystems. The discussion here is about what the uAPI should look > > like in a fairly abstract way. When we say 'dev/sva' it just some > > placeholder for a shared cdev that provides the necessary > > dis-aggregated functionality > > > > It could be an existing cdev with broader functionaltiy, it could > > really be /dev/iommu, etc. This is up to the folks building it to > > decide. > > > > > I'm not expert on vDPA for now, but I saw you three open source > > > veterans have a similar idea for a place to cover IOMMU handling, > > > I think it may be a valuable thing to do. I said "may be" as I'm not > > > sure about Alex's opinion on such idea. But the sure thing is this > > > idea may introduce weird overlap even re-definition of existing > > > thing as I replied above. We need to evaluate the impact and mature > > > the idea step by step. > > > > This has happened before, uAPIs do get obsoleted and replaced with > > more general/better versions. It is often too hard to create a uAPI > > that lasts for decades when the HW landscape is constantly changing > > and sometime a reset is needed. > > I'm throwing this out with a lot of hesitation, but I'm going to :-) > > So we have been disussing this for months now, with some high level vision > trying to get the uAPI's solidified with a vDPA hardware that might > potentially have SIOV/SVM like extensions in hardware which actualy doesn't > exist today. Understood people have plans. > Given that vDPA today has diverged already with duplicating use of IOMMU > api's without making an effort to gravitate to /dev/iommu as how you are > proposing. I see it more like, given that we already know we have multiple users of IOMMU, adding new IOMMU focused features has to gravitate toward some kind of convergance. Currently things are not so bad, VDPA is just getting started and the current IOMMU feature set is not so big. PASID/vIOMMU/etc/et are all stressing this more, I think the responsibility falls to the people proposing these features to do the architecture work. > The question is should we hold hostage the current vSVM/vIOMMU efforts > without even having made an effort for current vDPA/VFIO convergence. I don't think it is "held hostage" it is a "no shortcuts" approach, there was always a recognition that future VDPA drivers will need some work to integrated with vIOMMU realted stuff. This is no different than the IMS discussion. The first proposed patch was really simple, but a layering violation. The correct solution was some wild 20 patch series modernizing how x86 interrupts works because it had outgrown itself. This general approach to use the shared MSI infrastructure was pointed out at the very beginning of IMS, BTW. Jason
