[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <360a3b91-1ac5-84c0-d34b-a4243fa748c4@redhat.com>
Date: Mon, 12 Aug 2019 10:44:51 +0800
From: Jason Wang <jasowang@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: kvm@...r.kernel.org, virtualization@...ts.linux-foundation.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, jgg@...pe.ca
Subject: Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
> On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
>> Hi all:
>>
>> This series try to fix several issues introduced by meta data
>> accelreation series. Please review.
>>
>> Changes from V4:
>> - switch to use spinlock synchronize MMU notifier with accessors
>>
>> Changes from V3:
>> - remove the unnecessary patch
>>
>> Changes from V2:
>> - use seqlck helper to synchronize MMU notifier with vhost worker
>>
>> Changes from V1:
>> - try not use RCU to syncrhonize MMU notifier with vhost worker
>> - set dirty pages after no readers
>> - return -EAGAIN only when we find the range is overlapped with
>> metadata
>>
>> Jason Wang (9):
>> vhost: don't set uaddr for invalid address
>> vhost: validate MMU notifier registration
>> vhost: fix vhost map leak
>> vhost: reset invalidate_count in vhost_set_vring_num_addr()
>> vhost: mark dirty pages during map uninit
>> vhost: don't do synchronize_rcu() in vhost_uninit_vq_maps()
>> vhost: do not use RCU to synchronize MMU notifier with worker
>> vhost: correctly set dirty pages in MMU notifiers callback
>> vhost: do not return -EAGAIN for non blocking invalidation too early
>>
>> drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------
>> drivers/vhost/vhost.h | 6 +-
>> 2 files changed, 122 insertions(+), 86 deletions(-)
> This generally looks more solid.
>
> But this amounts to a significant overhaul of the code.
>
> At this point how about we revert 7f466032dc9e5a61217f22ea34b2df932786bbfc
> for this release, and then re-apply a corrected version
> for the next one?
If possible, consider we've actually disabled the feature. How about
just queued those patches for next release?
Thanks
>
>> --
>> 2.18.1
Powered by blists - more mailing lists