From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 484AA43F47; Mon, 29 Apr 2024 18:27:49 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C9FC6402A3; Mon, 29 Apr 2024 18:27:48 +0200 (CEST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id 96C104029C for ; Mon, 29 Apr 2024 18:27:46 +0200 (CEST) Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1e65a1370b7so43546785ad.3 for ; Mon, 29 Apr 2024 09:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1714408066; x=1715012866; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=hY8VQGBOmhDXTJqoioYT+viiFC5k/hZ0lQpA1PF+ouU=; b=yoLFZdN55uvFCgGcMdJ9y9UQ2cqqUewT7a8AJRPggaico0JTSKG0MCFCFFcRi5GV+K NEkbQzpDmXneq/2b25Oy05gYGaVClYQbungRxDXRczXOsJly64pFkkt02u4Is9SHif2i bG3gT9s8YsSv4gCU8/Z2BQJiahtQ9GtnhjSKW/siRhNMC50iidTTEwLPMns59tsb/icj a73ECCHfHD2TM/3CdJbrRq33Ie83B0uXrRW/2C6ZhBfRn67eJ+3Phd7SmjUhinqbwx/h xQsDZ2Q57wQ2H0jBtKU8jWaeGGT9uxn9iAgjzjW+tCd7sogFjblX5rTTtrIjDYqTGYk5 XgXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714408066; x=1715012866; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hY8VQGBOmhDXTJqoioYT+viiFC5k/hZ0lQpA1PF+ouU=; b=rDrkOKq4PHo4Y78PIvz2QEo8hs+nrZ+1jFZU/QHg57PhVu9uMsM4Xc9WrgTRFPViR/ vCAXCL2MFVprDv+nlC9ut9dljumEUAO8Vdm6MTa9y7FkCihTxfRJ9Z+j2lCanYWryEzD uSrKiR8gDDFp0meRS1HCVRUK6H+t5J6JsMcmRObik6fDWjBYeZlvlwKfDR+yCQZH2anX mMYjkU6OZITVZQ+ONpRvhGKFQuVhZraKgA8/Ku5FgTePoExJ6aKIeO4jz3uv9y0u1jvR c5Gd4XZLswz6HPCEsyt2cNF8Fge5LACGLH7IrJ5J45qTiKLg9h9K5phl3oQh4m6HkPwd F98g== X-Forwarded-Encrypted: i=1; AJvYcCVyWRQ7oDq9VgKfvIKuh89ieL/SzTAYtuCFxnH5LoJI4uzEyBaFvZjeMbuxQ5foRerv3IbuaZj2IGZM4eI= X-Gm-Message-State: AOJu0Yz5TP6BA18LUg8AxkWgIStJWS8+HLgKv003V6IQAFdXWrXH/u5B FJuhI7I1P3e/9++4dcNVLaUbk9yzBwXpagnNR3Amwnrii+U59xhmXGBjhO9MvzTHl0nzxXlRMQN eVSg= X-Google-Smtp-Source: AGHT+IGiYJMWfVMWR3rkgkK7fGFyfIpkbORx+qVWcm0ugNcJxP1XwwC0qMCANxpryTQ3MwjbDabT+w== X-Received: by 2002:a17:902:9a42:b0:1e5:1071:5631 with SMTP id x2-20020a1709029a4200b001e510715631mr10410311plv.65.1714408065646; Mon, 29 Apr 2024 09:27:45 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id b21-20020a170902d89500b001e44578dccasm20555601plz.254.2024.04.29.09.27.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Apr 2024 09:27:45 -0700 (PDT) Date: Mon, 29 Apr 2024 09:27:42 -0700 From: Stephen Hemminger To: Maxime Coquelin Cc: Kangjie Xu , chenbo.xia@intel.com, dev@dpdk.org, xuanzhuo@linux.alibaba.com, hengqi@linux.alibaba.com, jasowang@redhat.com, mst@redhat.com Subject: Re: [PATCH v3 1/2] vhost: destroy device when all vqs are inactive Message-ID: <20240429092742.3e717890@hermes.local> In-Reply-To: <72b778f6-c813-4b20-1b9c-834d22191a5b@redhat.com> References: <0383bb821dd65d8511a91e9f13b193230be59557.1662952732.git.kangjie.xu@linux.alibaba.com> <72b778f6-c813-4b20-1b9c-834d22191a5b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 11 Oct 2022 18:44:28 +0200 Maxime Coquelin wrote: > On 9/12/22 05:36, Kangjie Xu wrote: > > We change the behavior of vhost_user_get_vring_base(). Previosly, > > destroying a virtqueue will cause the whole device to be destroyed. > > The behavior is not specified in the vhost-user protocol. > > > > Thus, we refactor this part. The device will be destroyed only when > > all virtqueues in the device are going to be destroyed. > > > > This helps us to simplify the implementation when resetting a virtqueue. > > > > Signed-off-by: Kangjie Xu > > Signed-off-by: Xuan Zhuo > > --- > > lib/vhost/vhost_user.c | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/lib/vhost/vhost_user.c b/lib/vhost/vhost_user.c > > index 4ad28bac45..a9f0709f94 100644 > > --- a/lib/vhost/vhost_user.c > > +++ b/lib/vhost/vhost_user.c > > @@ -2088,10 +2088,16 @@ vhost_user_get_vring_base(struct virtio_net **pdev, > > { > > struct virtio_net *dev = *pdev; > > struct vhost_virtqueue *vq = dev->virtqueue[ctx->msg.payload.state.index]; > > + uint32_t i, num_live_vring = 0; > > uint64_t val; > > > > - /* We have to stop the queue (virtio) if it is running. */ > > - vhost_destroy_device_notify(dev); > > + /* Stop the device when vq is the last active queue */ > > + for (i = 0; i < dev->nr_vring; i++) > > + if (dev->virtqueue[i]->access_ok) > > + num_live_vring++; > > + > > + if (num_live_vring == 1 && vq->access_ok) > > + vhost_destroy_device_notify(dev); > > > > dev->flags &= ~VIRTIO_DEV_READY; > > dev->flags &= ~VIRTIO_DEV_VDPA_CONFIGURED; > > I think we are missing something here. > > We used to send the device destroy notification before getting the ring > indexes, in order to ensure that the application has stopped processing > the rings. > > With this patch, the application may still be polling the ring while we > get the ring indexes (e.g. a thread in the application may be in the > middle of rte_vhost_dequeue_burst() on that ring). So at best the ring > indexes returned to the Vhost-user master will be outdated. At worst, it > will crash the application because we call vring_invalidate() without > the vq's lock being taken. > > I think you should protect all the VQ indexes fetching and VQ deinit > using its access_lock. > > Maxime > Please address Maxime's feedback.