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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CB56CE79AB for ; Wed, 20 Sep 2023 07:48:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233964AbjITHsl (ORCPT ); Wed, 20 Sep 2023 03:48:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234008AbjITHsK (ORCPT ); Wed, 20 Sep 2023 03:48:10 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDF9D132 for ; Wed, 20 Sep 2023 00:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695196058; x=1726732058; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=6EIYxxBxmaM+623ONioCHxvpX1okslSwTEtsPJQ94lQ=; b=NhDR5M7Bn6RnDrXhT9dsuGgdc1ZlnunrOK8v0Nrf0EGWHnS10Vs3xS+9 YqYOn1tJZHgXYc+EgMa93CNtd/jmLG/0mlYK1RPct9Cn6lkgPzTSe8ssO nEZdcwm2DSJgsDTnDvbEwcvi5uPzVOf153dvP6LNJrvxxtKLx0Ip4OU2D jF4mLmHkj7kaQkw+VkyEVKK1fT9M3KyfMbZdMK1wo9BWzf3RhqJgEYGdE SN36HIWYwzK0wmJ7cVlYmvAhqgR8TF0TWuIZ6aykOPX0ueKoj66gYsMoR jm4LlHGz+WTyt828+yqf5zgU26x3GtZBsWJvImmMyHvlaEEoyFv0jMaZs g==; X-IronPort-AV: E=McAfee;i="6600,9927,10838"; a="444247258" X-IronPort-AV: E=Sophos;i="6.02,161,1688454000"; d="scan'208";a="444247258" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2023 00:47:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10838"; a="920180951" X-IronPort-AV: E=Sophos;i="6.02,161,1688454000"; d="scan'208";a="920180951" Received: from lingshan-mobl.ccr.corp.intel.com (HELO [10.93.14.5]) ([10.93.14.5]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2023 00:47:31 -0700 Message-ID: <40765650-ba6e-357a-cf73-ff6a0288c0e8@intel.com> Date: Wed, 20 Sep 2023 15:47:29 +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 Subject: Re: [virtio-dev] Re: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg Content-Language: en-US To: Parav Pandit , "Chen, Jiqian" , "Michael S. Tsirkin" Cc: Gerd Hoffmann , Jason Wang , Xuan Zhuo , David Airlie , Gurchetan Singh , Chia-I Wu , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Robert Beckett , Mikhail Golubev-Ciuchea , "virtio-comment@lists.oasis-open.org" , "virtio-dev@lists.oasis-open.org" , "qemu-devel@nongnu.org" , "linux-kernel@vger.kernel.org" , Stefano Stabellini , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , "Deucher, Alexander" , "Koenig, Christian" , "Hildebrand, Stewart" , Xenia Ragiadakou , "Huang, Honglei1" , "Zhang, Julia" , "Huang, Ray" References: <20230919114242.2283646-1-Jiqian.Chen@amd.com> <20230919114242.2283646-2-Jiqian.Chen@amd.com> <20230919082802-mutt-send-email-mst@kernel.org> <701bb67c-c52d-4eb3-a6ed-f73bd5d0ff33@intel.com> From: "Zhu, Lingshan" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/20/2023 3:35 PM, Parav Pandit wrote: >> From: Zhu, Lingshan >> Sent: Wednesday, September 20, 2023 1:00 PM >> >> On 9/20/2023 3:24 PM, Chen, Jiqian wrote: >>> Hi Lingshan, >>> It seems you reply to the wrong email thread. They are not related to my >> patch. >> These reply to Parva's comments. >> @Parva, if you want to discuss more about live migration, please reply in my >> thread, lets don't flood here. > You made the point that "this is not live migration". > I am not discussing live migration in this thread. > > I replied for the point that device restoration from suspend for physical and hypevisor based device is not a 40nsec worth of work to restore by just doing a register write. > This is not live or device migration. This is restoring the device context initiated by the driver owning the device. restore the device context should be done by the hypervisor before setting DRIVER_OK and waking up the guest, not a concern here, out of spec