[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3e4a8bea-f187-3843-c1d1-75d0b86a137b@redhat.com>
Date: Tue, 13 Oct 2020 13:40:44 +0800
From: Jason Wang <jasowang@...hat.com>
To: Eli Cohen <elic@...dia.com>
Cc: mst@...hat.com, lulu@...hat.com, kvm@...r.kernel.org,
virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, rob.miller@...adcom.com,
lingshan.zhu@...el.com, eperezma@...hat.com, hanand@...inx.com,
mhabets@...arflare.com, amorenoz@...hat.com,
maxime.coquelin@...hat.com, stefanha@...hat.com,
sgarzare@...hat.com
Subject: Re: [RFC PATCH 10/24] vdpa: introduce config operations for
associating ASID to a virtqueue group
On 2020/10/12 下午4:17, Eli Cohen wrote:
> On Mon, Oct 12, 2020 at 03:45:10PM +0800, Jason Wang wrote:
>>> So in theory we can have several asid's (for different virtqueues), each
>>> one should be followed by a specific set_map call. If this is so, how do
>>> I know if I met all the conditions run my driver? Maybe we need another
>>> callback to let the driver know it should not expect more set_maps().
>>
>> This should work similarly as in the past. Two parts of the work is expected
>> to be done by the driver:
>>
>> 1) store the mapping somewhere (e.g hardware) during set_map()
>> 2) associating mapping with a specific virtqueue
>>
>> The only difference is that more than one mapping is used now.
> ok, so like today, I will always get DRIVER_OK after I got all the
> set_maps(), right?
Yes.
Thanks
>
>> For the issue of more set_maps(), driver should be always ready for the new
>> set_maps() call instead of not expecting new set_maps() since guest memory
>> topology could be changed due to several reasons.
>>
>> Qemu or vhost-vDPA will try their best to avoid the frequency of set_maps()
>> for better performance (e.g through batched IOTLB updating). E.g there
>> should be at most one set_map() during one time of guest booting.
>>
>>
Powered by blists - more mailing lists