[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <914081d6-40ee-f184-ff43-c3d4cd885fba@redhat.com>
Date: Thu, 7 Nov 2019 12:08:08 +0800
From: Jason Wang <jasowang@...hat.com>
To: Tiwei Bie <tiwei.bie@...el.com>
Cc: "Michael S. Tsirkin" <mst@...hat.com>, alex.williamson@...hat.com,
maxime.coquelin@...hat.com, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, virtualization@...ts.linux-foundation.org,
netdev@...r.kernel.org, dan.daly@...el.com,
cunming.liang@...el.com, zhihong.wang@...el.com,
lingshan.zhu@...el.com
Subject: Re: [PATCH v5] vhost: introduce mdev based hardware backend
On 2019/11/6 下午10:49, Tiwei Bie wrote:
>>>>>> + default:
>>>>>> + /*
>>>>>> + * VHOST_SET_MEM_TABLE, VHOST_SET_LOG_BASE, and
>>>>>> + * VHOST_SET_LOG_FD are not used yet.
>>>>>> + */
>>>>> If we don't even use them, there's probably no need to call
>>>>> vhost_dev_ioctl(). This may help to avoid confusion when we want to develop
>>>>> new API for e.g dirty page tracking.
>>>> Good point. It's better to reject these ioctls for now.
>>>>
>>>> PS. One thing I may need to clarify is that, we need the
>>>> VHOST_SET_OWNER ioctl to get the vq->handle_kick to work.
>>>> So if we don't call vhost_dev_ioctl(), we will need to
>>>> call vhost_dev_set_owner() directly.
>> I may miss something, it looks to me the there's no owner check in
>> vhost_vring_ioctl() and the vhost_poll_start() can make sure handle_kick
>> works?
> Yeah, there is no owner check in vhost_vring_ioctl().
> IIUC, vhost_poll_start() will start polling the file. And when
> event arrives, vhost_poll_wakeup() will be called, and it will
> queue work to work_list and wakeup worker to finish the work.
> And the worker is created by vhost_dev_set_owner().
>
Right, rethink about this. It looks to me we need:
- Keep VHOST_SET_OWNER, this could be used for future control vq where
it needs a kthread to access the userspace memory
- Temporarily filter SET_LOG_BASE and SET_LOG_FD until we finalize the
API for dirty page tracking.
- For kick through kthread, it looks sub-optimal but we can address this
in the future, e.g call handle_vq_kick directly in vhost_poll_queue
(probably a flag for vhost_poll) and deal with the synchronization in
vhost_poll_flush carefully.
Thanks
Powered by blists - more mailing lists