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 96E1BCA0EC3 for ; Tue, 12 Sep 2023 09:06:16 +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 EFE0D7B17E for ; Tue, 12 Sep 2023 09:06:15 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id BB08D986630 for ; Tue, 12 Sep 2023 09:06:15 +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 99D11983E27; Tue, 12 Sep 2023 09:06:15 +0000 (UTC) Mailing-List: contact virtio-dev-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 87449986485; Tue, 12 Sep 2023 09:06:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-IronPort-AV: E=McAfee;i="6600,9927,10830"; a="409273632" X-IronPort-AV: E=Sophos;i="6.02,245,1688454000"; d="scan'208";a="409273632" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10830"; a="886881951" X-IronPort-AV: E=Sophos;i="6.02,245,1688454000"; d="scan'208";a="886881951" Message-ID: <8bd1c228-856a-9454-752d-750997c4f4db@intel.com> Date: Tue, 12 Sep 2023 17:06:00 +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.15.0 Content-Language: en-US To: Parav Pandit , Jason Wang Cc: "Michael S. Tsirkin" , "eperezma@redhat.com" , "cohuck@redhat.com" , "stefanha@redhat.com" , "virtio-comment@lists.oasis-open.org" , "virtio-dev@lists.oasis-open.org" References: <20230906081637.32185-1-lingshan.zhu@intel.com> <88b8b14c-88d8-1f76-0e6e-7b5f334171f1@intel.com> <2b3e8da1-5cbb-f990-0c1d-c0e894a73486@intel.com> <17514b93-2da4-42b3-a5bf-b96358a7a875@intel.com> <9fabd346-9b6f-a727-3de8-813ec3570772@intel.com> <2baee870-bf38-5d83-0543-1d0a68f8e651@intel.com> From: "Zhu, Lingshan" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [virtio-dev] Re: [virtio-comment] [PATCH 5/5] virtio-pci: implement VIRTIO_F_QUEUE_STATE On 9/12/2023 3:53 PM, Parav Pandit wrote: >> From: Zhu, Lingshan >> Sent: Tuesday, September 12, 2023 12:59 PM >> >> On 9/12/2023 2:49 PM, Parav Pandit wrote: >>>> From: Zhu, Lingshan >>>> Sent: Tuesday, September 12, 2023 12:08 PM >>>> >>>> On 9/12/2023 1:51 PM, Parav Pandit wrote: >>>>>> From: Zhu, Lingshan >>>>>> Sent: Tuesday, September 12, 2023 9:19 AM >>>>>> >>>>>> On 9/11/2023 7:50 PM, Parav Pandit wrote: >>>>>>>> From: Zhu, Lingshan >>>>>>>> Sent: Monday, September 11, 2023 3:03 PM By the way, do you see >>>>>>>> anything we need to improve in this series? >>>>>>> Admin commands for passthrough devices of [1] is comprehensive >>>>>>> proposal >>>>>> covering all the aspects. >>>>>>> To me [1] is superset work that covers all needed functionality >>>>>>> and downtime >>>>>> aspects. >>>>>>> I plan to improve [1] with v1 this week by extending device >>>>>>> context and >>>>>> addressing other review comments. >>>>>>> [1] >>>>>>> https://lists.oasis-open.org/archives/virtio-comment/202309/msg000 >>>>>>> 61 >>>>>>> .h >>>>>>> tml >>>>>> I am not sure, we have discussed a lot about the potential issues >>>>>> in the treads. I guess we should resolve them first. E.g., nested use cases. >>>>> You are using nesting use case as the _only_ use case and attempt to >>>>> steer >>>> using that. >>>>> Not right. >>>>> >>>>> If you want to discuss, then lets have both the use cases, attempt >>>>> to converge >>>> and if we can its really good. >>>>> If we cannot, both requirements should be handled differently. >>>> Isn't nested a clear use case that should be supported? >>> Most users who care for running real applications and real performance, have >> not asked for nesting. >>> It is not mandatory case; it may be required for some users. >>> I don’t know who needs M level nesting and how cpu also support its >> acceleration etc to run some reasonable workload. >> Nested is a common use case and it is mandatory. > Maybe it is common case for the users you interact with, it is required for some complicated mode. > How many level of nesting 10, 2, 100? > > I don’t see a point of debating that "nesting is the only case and mediation is the only way" to do device migration. > > As I repeatedly acknowledged, > We are open to converge on doing administration commands that can work for passthrough and nested way. > > I just don’t see how nested solution can work without any mediation, as everything you do touches device reset and FLR flow and it practically breaks the PCI specification with these side band registers and faking device reset and FLR when asked. > This is the primary reason; I am less inclined to go the in-band method. > Until now, no one technically explained how it can even work on question from yesterday. > > And if there is one, please explain, I am very interested to learn, how is this done without hacks where device reset by guest _actually_ reset the underlying member device while the dirty page tracking is also ongoing. > > So, my humble request is, try to work towards co-existing both the methods if possible, rather than doing either or mode. If you want AQ used for LM, it should support nested anyway, don't break user logic. This (my)series can support nested. > > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org