Messages in this thread | | | Subject | Re: [PATCH 3/5] vDPA: introduce vDPA bus | From | Jason Wang <> | Date | Tue, 21 Jan 2020 15:57:29 +0800 |
| |
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
>
| |