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 E5DDBCE79CE for ; Wed, 20 Sep 2023 12:16:20 +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 56CC871C95 for ; Wed, 20 Sep 2023 12:16:20 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 2F7C5986679 for ; Wed, 20 Sep 2023 12:16:20 +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 12DD398666A; Wed, 20 Sep 2023 12:16:20 +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 02FA498666B for ; Wed, 20 Sep 2023 12:16:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="411149729" X-IronPort-AV: E=Sophos;i="6.03,162,1694761200"; d="scan'208";a="411149729" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10839"; a="723251285" X-IronPort-AV: E=Sophos;i="6.03,162,1694761200"; d="scan'208";a="723251285" Message-ID: Date: Wed, 20 Sep 2023 20:16:13 +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.1 Content-Language: en-US To: "Michael S. Tsirkin" Cc: Parav Pandit , "virtio-dev@lists.oasis-open.org" , Jason Wang References: <213a0f94-cee2-d8c5-3c5d-d2d7fc920e75@intel.com> <5f01772f-eb27-bfe0-7f69-b83fbd90dda0@intel.com> <20230918144312-mutt-send-email-mst@kernel.org> <20230920054836-mutt-send-email-mst@kernel.org> <2f67fb85-2238-9c34-a265-b0f97b7ab7e1@intel.com> <20230920075243-mutt-send-email-mst@kernel.org> From: "Zhu, Lingshan" In-Reply-To: <20230920075243-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state On 9/20/2023 8:05 PM, Michael S. Tsirkin wrote: > On Wed, Sep 20, 2023 at 07:22:32PM +0800, Zhu, Lingshan wrote: >> >> On 9/20/2023 6:36 PM, Michael S. Tsirkin wrote: >>> On Wed, Sep 20, 2023 at 02:06:13PM +0800, Zhu, Lingshan wrote: >>>> On 9/19/2023 2:49 AM, Michael S. Tsirkin wrote: >>>>> On Mon, Sep 18, 2023 at 06:41:55PM +0000, Parav Pandit wrote: >>>>>>> Please refer to the code for setting FEATURES_OK. >>>>>> It wont work when one needs to suspend the device. >>>>>> There is no point of doing such work over registers as fundamental framework is over the AQ. >>>>> Well not really. It's over admin commands. When these were built the >>>>> intent always was that it's possible to use admin commands through >>>>> another interface, other than admin queue. Is there a problem >>>>> implementing admin commands over a memory BAR? For example, I can see >>>>> an "admin command" capability pointing at a BAR where >>>>> commands are supplied, and using a new group type referring to >>>>> device itself. >>>> I am not sure, if a bar cap would be implemented as a proxy for the admin vq >>>> based live migration. >>> Not a proxy for a vq in that there's no vq then. >> I think if the driver sends admin commands through a VF's bar, then >> VF forwards the admin commands to the PF, it acts like a proxy, >> or an agent. Anyway it takes admin commands. > Why send them to the PF? They are controlling the VF anyway. I think its still too heavy compared to this series proposal > >> So the problems we have discussed still exist. >>>> then the problems of admin vq LM that we have >>>> discussed >>>> still exist. >>> I freely admit the finer points of this extended flamewar have been lost >>> on me, and I wager I'm not the only one. I thought you wanted to migrate >>> the device just by accessing the device itself (e.g. the VF) without >>> accessing other devices (e.g. the PF), while Parav wants it in a >>> separate device so the whole of the device itself can passed through to >>> guest. Isn't this, fundamentally, the issue? >> we are implementing basic facilities for live migration. >> >> We have pointed out lots of issues, there are many discussions with >> Jason and Parav about the problems in migration by admin vq, for example: >> security, QOS and nested. > /me shrugs > Thanks for the summary I guess. Same applies to almost any proposal. > What would help make progress is an explanation why this has grown into > a megathread. Do you understand Parav's thoughts well enough to > summarize them? as far as I see, I don't see admin vq as must for live migration. and it does not serve nested for sure. > >>>> the bar is only a proxy, doesn't fix anything. and even larger >>>> side channel attacking surface: vf-->pf-->vf >>> In this model there's no pf. BAR belongs to vf itself >>> and you submit commands for the VF through its BAR. >>> Just separate from the pci config space. >> If using the bar to process admin commands, >> is this solution too heavy compared to my proposal in this series? > somewhat - because it's more comprehensive - you can actually > migrate a device using it. > this series just begins to define how to poke at some > of the vq state - it's a subset of the necessary functionality. > > And it will give you a bunch of side benefits, such as > support for legacy compat commands that were merged. next version will include in-flight descriptors and dirty page tracking. I failed to process the comments for legacy. legacy devices are defined by code than the spec, if wants to migrate legacy devices, maybe working on QEMU first > > > >>> The whole attacking surface discussion is also puzzling. We either are >>> or are not discussing confidential computing/TDI. I couldn't figure >>> it out. This needs a separate thread I think. >> I agree confidential computing is out of spec. Parva mentioned TDISP and >> even >> in TDISP spec, it explicitly defined some attacking model, and PF is an >> example. >> >> It is out of spec anyway. > OK so we are ignoring TDISP applications for now? Everyone agrees on > that? sure > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org