On 2020/1/21 下午2:01, Shahaf Shuler wrote:

Tuesday, January 21, 2020 12:00 AM, Michael S. Tsirkin:

quoted

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

On Mon, Jan 20, 2020 at 09:47:18PM +0000, Shahaf Shuler wrote:

quoted

Monday, January 20, 2020 11:25 PM, Michael S. Tsirkin:

quoted

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

On Mon, Jan 20, 2020 at 08:51:43PM +0000, Shahaf Shuler wrote:

quoted

Monday, January 20, 2020 7:50 PM, Jason Gunthorpe:

quoted

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

On Mon, Jan 20, 2020 at 04:43:53PM +0800, Jason Wang wrote:

quoted

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().

quoted

quoted

quoted

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.

quoted

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