Re: [PATCH 3/5] vDPA: introduce vDPA bus

[Jason Wang]

On 2020/1/21 äå2:01, Shahaf Shuler wrote:
> Tuesday, January 21, 2020 12:00 AM, Michael S. Tsirkin:
> > Subject: Re: [PATCH 3/5] vDPA: introduce vDPA bus
> >
> > On Mon, Jan 20, 2020 at 09:47:18PM +0000, Shahaf Shuler wrote:
> > > Monday, January 20, 2020 11:25 PM, Michael S. Tsirkin:
> > > > Subject: Re: [PATCH 3/5] vDPA: introduce vDPA bus
> > > >
> > > > On Mon, Jan 20, 2020 at 08:51:43PM +0000, Shahaf Shuler wrote:
> > > > > Monday, January 20, 2020 7:50 PM, Jason Gunthorpe:
> > > > > > Subject: Re: [PATCH 3/5] vDPA: introduce vDPA bus
> > > > > >
> > > > > > On Mon, Jan 20, 2020 at 04:43:53PM +0800, Jason Wang wrote:
> > > > > > > This is similar to the design of platform IOMMU part of
> > > > > > > vhost-vdpa. We decide to send diffs to platform IOMMU there.
> > > > > > > If it's ok to do that in driver, we can replace set_map with
> > > > > > > incremental API
> > > > like map()/unmap().
> > > > > > > Then driver need to maintain rbtree itself.
> > > > > > I think we really need to see two modes, one where there is a
> > > > > > fixed translation without dynamic vIOMMU driven changes and one
> > > > > > that supports vIOMMU.
> > > > > >
> > > > > > There are different optimization goals in the drivers for these
> > > > > > two configurations.
> > > > > +1.
> > > > > It will be best to have one API for static config (i.e. mapping
> > > > > can be set only before virtio device gets active), and one API for
> > > > > dynamic changes that can be set after the virtio device is active.
> > > > Frankly I don't see when we'd use the static one.
> > > > Memory hotplug is enabled for most guests...
> > > The fact memory hotplug is enabled doesn't necessarily means there is not
> > cold-plugged memory on the hot plugged slots.
> > > So your claim is majority of guests are deployed w/o any cold-plugged
> > memory?
> >
> > Sorry for not being clear. I was merely saying that dynamic one can't be
> > optional, and static one can. So how about we start just with the dynamic
> > one, then add the static one as a later optimization?
> Since we have the use case (cold plugged memory to guest, e.g. when populated w/ hugepages) I think we should start w/ both. The static one can be optional for drivers.
>
> Moreover am not yet clear about the suggested API for dynamic, can you share the prototype you have in mind?
> Also will it be :
> 1. multiple add_map and then flag the driver to set
> Or
> 2. each add_map should be set by the driver as stand alone.


For dynamic one, it looks to me that introducing add_map()/del_map() bus 
operations is much more cleaner than reusing current set_map() one.

Thanks


>