From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5D8F9EB64D8 for ; Wed, 14 Jun 2023 06:11:38 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 82C6A7C6A5 for ; Wed, 14 Jun 2023 06:11:37 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 5BA1198668C for ; Wed, 14 Jun 2023 06:11:37 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 489C8986665; Wed, 14 Jun 2023 06:11:37 +0000 (UTC) Mailing-List: contact virtio-comment-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 34686986666 for ; Wed, 14 Jun 2023 06:11:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-IronPort-AV: E=McAfee;i="6600,9927,10740"; a="357410557" X-IronPort-AV: E=Sophos;i="6.00,241,1681196400"; d="scan'208";a="357410557" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10740"; a="689284524" X-IronPort-AV: E=Sophos;i="6.00,241,1681196400"; d="scan'208";a="689284524" Message-ID: <476b3ec4-0a19-2f61-4d2a-e4badfbeb499@intel.com> Date: Wed, 14 Jun 2023 14:11:26 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.12.0 Content-Language: en-US To: Parav Pandit , "Michael S. Tsirkin" Cc: Eugenio Perez Martin , Jason Wang , Xuan Zhuo , "virtio-comment@lists.oasis-open.org" , Laurent Vivier , Cindy Lu , "cohuck@redhat.com" , "alvaro.karsz@solid-run.com" , Liuxiangdong , Gautam Dawar , "longpeng2@huawei.com" , Dragos Tatulea , "stefanha@redhat.com" , Harpreet Singh Anand , Stefano Garzarella , Heng Qi , Shannon Nelson , Max Gurtovoy , "si-wei.liu@oracle.com" References: <20230608180617-mutt-send-email-mst@kernel.org> <20230609115250-mutt-send-email-mst@kernel.org> <20230613034216-mutt-send-email-mst@kernel.org> <20230613035132-mutt-send-email-mst@kernel.org> <20230613154823-mutt-send-email-mst@kernel.org> <20230613173837-mutt-send-email-mst@kernel.org> From: "Zhu, Lingshan" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [virtio-comment] Re: [PATCH 0/2] Selective queue enabling On 6/14/2023 12:32 PM, Parav Pandit wrote: > >> From: Zhu, Lingshan >> Sent: Wednesday, June 14, 2023 12:27 AM >>> If a device has assumed that queue_reset must be done after DRIVER_OK >>> stage because until that point the device is not "live", Such device needs the >> fix. >> I think queue_reset just resets the queue and its fields including the >> queue_enable. DRIVER_OK is not a must for performing a queue_reset, My >> understanding is: >> - before DRIVER_OK, the driver can re-config the queue anytime, doesn't need >> a reset_queue > Before DRIVER_OK stage, to reconfigure a queue, driver needs to write queue_enable = 0. > This is not allowed in the spec. > So driver need to use queue_reset to reconfigure. The spec requires the driver config all other fields before set queue_enable. I am not sure whether there are real occurring cases that re-config the vq fields between queue_enable and DRIVER_OK in the initialization. But I agree maybe we should allow set queue_enable = 0. This reset may happen after DRIVER_OK. > >> - after DRIVER_OK, the driver has to reset the queue to re-config the queue. >> Because a queue is considered alive when both DRIVER_OK && queue_enable, >> and resetting a queue also set queue_enable to zero. >> >> At the end of the migration, hypervisor should reset the queues and config the >> queues with the guest configurations and enable the queues, right? > The migration for non vdpa world would not require any of the queue enable/disable flow because device is migrated (paused) with its current state. > And it can resume from where it left off. For non-vdpa cases, it still require to migrate the states like MQ which is controlled by cvq. This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/