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 48CEACA0ECA for ; Tue, 12 Sep 2023 10:17:33 +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 B0B9621190 for ; Tue, 12 Sep 2023 10:17:32 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id A932E986630 for ; Tue, 12 Sep 2023 10:17:32 +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 9E28C986485; Tue, 12 Sep 2023 10:17:32 +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 8E35A98648C; Tue, 12 Sep 2023 10:17:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-IronPort-AV: E=McAfee;i="6600,9927,10830"; a="375662821" X-IronPort-AV: E=Sophos;i="6.02,139,1688454000"; d="scan'208";a="375662821" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10830"; a="772941557" X-IronPort-AV: E=Sophos;i="6.02,139,1688454000"; d="scan'208";a="772941557" Message-ID: <4c39bfe6-1acf-6ee7-2a0c-1861fa680eb4@intel.com> Date: Tue, 12 Sep 2023 18:17:18 +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> <8bd1c228-856a-9454-752d-750997c4f4db@intel.com> From: "Zhu, Lingshan" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [virtio-dev] Re: [virtio-comment] [PATCH 5/5] virtio-pci: implement VIRTIO_F_QUEUE_STATE On 9/12/2023 5:28 PM, Parav Pandit wrote: >> From: Zhu, Lingshan >> Sent: Tuesday, September 12, 2023 2:36 PM >> If you want AQ used for LM, it should support nested anyway, don't break user >> logic. > You ignored the other part of my question when you asked above. > i.e. a PCI transport do not allow such weird bifurcation. I failed to process your comment. Do you mean the registers don't support nested? >> >> This (my)series can support nested. > Maybe it does, with hacking the device reset and FLR sequence, without dirty tracking, without P2P support, without passthrough mode. > All these requirements are not addressed. > > If you intent to cover both requirements, lets work towards it to see if it can converge, if there are technical challenges, > then there is no point in pushing to claim that in-band VF with mediation is the only way to move forward. Why do you need P2P? Why FLR and reset are concerned? Why do you think dirty page tracking is not supported? > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org