qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] Revert "vhost-user: Monitor slave channel in vhost_user_


From: Maxime Coquelin
Subject: Re: [PATCH 1/2] Revert "vhost-user: Monitor slave channel in vhost_user_read()"
Date: Fri, 20 Jan 2023 16:03:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0



On 1/19/23 18:24, Greg Kurz wrote:
This reverts commit db8a3772e300c1a656331a92da0785d81667dc81.

Motivation : this is breaking vhost-user with DPDK as reported in [0].

Received unexpected msg type. Expected 22 received 40
Fail to update device iotlb
Received unexpected msg type. Expected 40 received 22
Received unexpected msg type. Expected 22 received 11
Fail to update device iotlb
Received unexpected msg type. Expected 11 received 22
vhost VQ 1 ring restore failed: -71: Protocol error (71)
Received unexpected msg type. Expected 22 received 11
Fail to update device iotlb
Received unexpected msg type. Expected 11 received 22
vhost VQ 0 ring restore failed: -71: Protocol error (71)
unable to start vhost net: 71: falling back on userspace virtio

The failing sequence that leads to the first error is :
- QEMU sends a VHOST_USER_GET_STATUS (40) request to DPDK on the master
   socket
- QEMU starts a nested event loop in order to wait for the
   VHOST_USER_GET_STATUS response and to be able to process messages from
   the slave channel
- DPDK sends a couple of legitimate IOTLB miss messages on the slave
   channel
- QEMU processes each IOTLB request and sends VHOST_USER_IOTLB_MSG (22)
   updates on the master socket
- QEMU assumes to receive a response for the latest VHOST_USER_IOTLB_MSG
   but it gets the response for the VHOST_USER_GET_STATUS instead

The subsequent errors have the same root cause : the nested event loop
breaks the order by design. It lures QEMU to expect responses to the
latest message sent on the master socket to arrive first.

Since this was only needed for DAX enablement which is still not merged
upstream, just drop the code for now. A working solution will have to
be merged later on. Likely protect the master socket with a mutex
and service the slave channel with a separate thread, as discussed with
Maxime in the mail thread below.

[0] 
https://lore.kernel.org/qemu-devel/43145ede-89dc-280e-b953-6a2b436de395@redhat.com/

Reported-by: Yanghang Liu <yanghliu@redhat.com>
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2155173
Signed-off-by: Greg Kurz <groug@kaod.org>
---
  hw/virtio/vhost-user.c | 35 +++--------------------------------
  1 file changed, 3 insertions(+), 32 deletions(-)


Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>

Thanks,
Maxime




reply via email to

[Prev in Thread] Current Thread [Next in Thread]