On 2018年04月12日 01:00, Michael S. Tsirkin wrote:
On Wed, Apr 11, 2018 at 09:41:05PM +0800, Jason Wang wrote:
On 2018年04月11日 16:38, Tiwei Bie wrote:
On Wed, Apr 11, 2018 at 04:01:19PM +0800, Jason Wang wrote:
On 2018年04月11日 15:20, Tiwei Bie wrote:
This patch introduces VHOST_USER_PROTOCOL_F_NEED_ALL_IOTLB
feature for vhost-user. By default, vhost-user backend needs
to query the IOTLBs from QEMU after meeting unknown IOVAs.
With this protocol feature negotiated, QEMU will provide all
the IOTLBs to vhost-user backend without waiting for the
queries from backend. This is helpful when using a hardware
accelerator which is not able to handle unknown IOVAs at the
vhost-user backend.

Signed-off-by: Tiwei Bie<tiwei....@intel.com>
---
The idea of this patch is to let QEMU push all the IOTLBs
to vhost-user backend without waiting for the queries from
the backend. Because hardware accelerator at the vhost-user
backend may not be able to handle unknown IOVAs.

This is just a RFC for now. It seems that, it doesn't work
as expected when guest is using kernel driver (To handle
this case, it seems that some RAM regions' events also need
to be listened). Any comments would be appreciated! Thanks!
Interesting, a quick question is why this is needed? Can we just use exist
IOTLB update message?
Yeah, we are still using the existing IOTLB update messages
to send the IOTLB messages to backend. The only difference
is that, QEMU won't wait for the queries before sending the
IOTLB update messages.
Yes, my question is not very clear. I mean why must need a new feature bit?
It looks to me qemu code can work without this.

Thanks
Generally we avoid adding new messages without a protocol feature bit.
While careful analysis might sometimes prove it's not a strict
requirement, it's just overall a clean and robust approach.


Right but the looks like the patch does not introduce any new type of messages.

Thanks


Reply via email to