On 2020/1/21 下午7:09, Shahaf Shuler wrote:

Tuesday, January 21, 2020 10:35 AM, Jason Wang:

quoted

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


On 2020/1/21 下午4:15, Michael S. Tsirkin wrote:

quoted

On Tue, Jan 21, 2020 at 04:00:38PM +0800, Jason Wang wrote:

quoted

On 2020/1/21 下午1:47, Michael S. Tsirkin wrote:

quoted

On Tue, Jan 21, 2020 at 12:00:57PM +0800, Jason Wang wrote:

quoted

On 2020/1/21 上午1:49, Jason Gunthorpe wrote:

quoted

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

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.

I think in this case, you meant the method proposed by Shahaf that
sends diffs of "fixed translation" to device?

It would be kind of tricky to deal with the following case for example:

old map [4G, 16G) new map [4G, 8G)

If we do

1) flush [4G, 16G)
2) add [4G, 8G)

There could be a window between 1) and 2).

It requires the IOMMU that can do

1) remove [8G, 16G)
2) flush [8G, 16G)
3) change [4G, 8G)

....

Basically what I had in mind is something like qemu memory api

0. begin
1. remove [8G, 16G)
2. add [4G, 8G)
3. commit

This sounds more flexible e.g driver may choose to implement static
mapping one through commit. But a question here, it looks to me this
still requires the DMA to be synced with at least commit here.
Otherwise device may get DMA fault? Or device is expected to be paused

DMA during begin?

quoted

quoted

Thanks

For example, commit might switch one set of tables for another,
without need to pause DMA.

Yes, I think that works but need confirmation from Shahaf or Jason.

 From my side, as I wrote, I would like to see the suggested function prototype along w/ the definition of the expectation from driver upon calling those.
It is not 100% clear to me what should be the outcome of remove/flush/change/commit

Right, I can do this in next version after the discussion is converged.

Thanks