On Tue, Jun 29, 2021 at 11:29 AM Jason Wang <jasowang@xxxxxxxxxx> wrote:
OK, I see. If so, I prefer to only use noreply for set_status(). We do
在 2021/6/29 上午10:26, Yongji Xie 写道:
On Mon, Jun 28, 2021 at 12:40 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
在 2021/6/25 下午12:19, Yongji Xie 写道:We should not send messages to userspace in the FEATURES_OK case. So
Just notice this part in virtio_finalize_features():2b) for set_status(): simply relay the message to userspace, reply is noLooks good to me. And I think we can use the reply of the message to
needed. Userspace will use a command to update the status when the
datapath is stop. The the status could be fetched via get_stats().
2b looks more spec complaint.
update the status instead of introducing a new command.
virtio_add_status(dev, VIRTIO_CONFIG_S_FEATURES_OK);
status = dev->config->get_status(dev);
if (!(status & VIRTIO_CONFIG_S_FEATURES_OK)) {
So we no reply doesn't work for FEATURES_OK.
So my understanding is:
1) We must not use noreply for set_status()
2) We can use noreply for get_status(), but it requires a new ioctl to
update the status.
So it looks to me we need synchronize for both get_status() and
set_status().
the synchronization is not necessary.
As discussed previously, there could be a device that mandates some
features (VIRTIO_F_RING_PACKED). So it can choose to not accept
FEATURES_OK is packed virtqueue is not negotiated.
In this case we need to relay the message to userspace.
not set the status bit if the message is failed. In this way, we don't
need to change lots of virtio core codes to handle the failure of
set_status()/get_status().
Thanks,
Yongji