Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3919591imc; Thu, 14 Mar 2019 08:11:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxoGKXfqOL2Z+v1N7hCmZPvMycFGHEYmKbnkDFwG84RQD53WP+4Zig+rCMdky/v4vMEbhoA X-Received: by 2002:a62:110c:: with SMTP id z12mr50276949pfi.184.1552576291983; Thu, 14 Mar 2019 08:11:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552576291; cv=none; d=google.com; s=arc-20160816; b=Xld6xEHxEyRYDojAIuB5/ThcI00sDd9gwJkziZMvjS6Zqic7SOgkC9xSzqM1QzoMW5 +5Qys73xbdfMR81a6N3L71C9usGjdFhikfGEoKsG2f6v/snMyG6tfMp4JGn/8kl97Zj/ tjeauzl8q1yxoI/svebyxzJydKI84aj2h1igH4U3JJ9UwYefTvoZHL/bTQngk7DDMYrN +GN+DbS3wpwlpZzO74R8UVbqGBajDknkTShCv7fHgBDQAS0GfGdzrkowZyk0McquZuec Kep7vsoID5rdEpjmau/vXi+4HRsvcPunHhmUN7vgv6nWpjsR4GfyfWMoT4c/+GNv7F0P I9kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=QFv7XgSuT6xBTdO3jmwBeBBZOivd4lt0c9Ic6gJvH9I=; b=MHd7ulmhpuqM2y0JtMwds9dP8k9Zg0ARa/3nbKLCAO6PMBNfs33J+F7JSuriK+nbjy 8/wseH5uEi2NByNHAEA2zbXE1wS3HYUyODI1Kqgp17hFfcqzRQvH5fFuFq3sJ+AsMvkG tKRwQEzLdLVpc8NBCjn/5vlQODc0QTUO5n0ER/t6NI2JGzzKXh9TqQ1Vo4LLlJ9OTerh GvK06vkU+Olcnf+6VcGbED3jJRdDZ2VvrRTLqhNCEtHQlngAOMQCzm8DMeVGZ4RKEx5Z JgMDen64KwofCwfYD+POQrSFq96x7kZug8xxtkb+qccKk/NFXfFexpc+Z6rhMLlmVlIA 84IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="O97VXI/E"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j26si12645437pff.289.2019.03.14.08.11.16; Thu, 14 Mar 2019 08:11:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="O97VXI/E"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727044AbfCNPKT (ORCPT + 99 others); Thu, 14 Mar 2019 11:10:19 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:43751 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726691AbfCNPKS (ORCPT ); Thu, 14 Mar 2019 11:10:18 -0400 Received: by mail-lf1-f67.google.com with SMTP id g7so4489404lfh.10; Thu, 14 Mar 2019 08:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=QFv7XgSuT6xBTdO3jmwBeBBZOivd4lt0c9Ic6gJvH9I=; b=O97VXI/EDTg68BPr4Zgh72YNRtAhr4mALMd/1ETaQFtbcILFB9E0IhSYeHLgSXrHXk pEJ21a2rLyWA0UG1JY1aEEPagcxKVev2pTz7PUmu6B6iOSYvFivKbmvZDwN1/2NrFW8T AOYf43SATgS9W+ZlHnPgOQ0uiAzPeTCDN1/3ngPIntaiB80+HjrxIu4so/AxxiAycG8L 3ceTHj3BkfAtTuaglDzuNhZdLIzJ0o+Z/aRVoXrt7b7HvlFiF7nbccM1E1/qsu/YoNr3 zHg6DDMZj3ee8LGW4aixDcssOp2EvgcQ8Rb9axLy98VIv5J79xCoFkMWP2XujHwXHTCP tmBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=QFv7XgSuT6xBTdO3jmwBeBBZOivd4lt0c9Ic6gJvH9I=; b=YBUDIXsxkXf1kE9zZQ4Xo18OYvpyTeiFtiRRHEcF3mPaGDHxaHudIpSEi8kq34gxMm ZKynuAXWE79XT4uNXdFK63s2Bs577Fld23Mm97HYTdZKk4sc30LbUZ1g1DmFJZu3KbfJ twdN7XOYxmxBjKlt9dDqmYskBChiD27/I29z/WzFnXe7Y7+pFjVrhfA33QhZZUtZ1NGS yWbAF7Mw4uZX7pYXOZDMub57nqrUsapGZRSd9z3UOrD8455ZergaND6n6Rj1zLOqGXH9 dOqYpXqWJningIw+UTA1UOYqSM6rKmNOT92wswyhnraVGauxNxbMC9q03gnXh9ckQtiL j7ng== X-Gm-Message-State: APjAAAXFEhRD9RN2aAwaoOf5dW9Z7iuZytDeGUI9WjGoR0sigiwLgWje 6mBPNa2w169G3k5BaS2WE3k= X-Received: by 2002:a19:48d5:: with SMTP id v204mr16000029lfa.70.1552576216324; Thu, 14 Mar 2019 08:10:16 -0700 (PDT) Received: from [10.17.182.20] (ll-74.141.223.85.sovam.net.ua. [85.223.141.74]) by smtp.gmail.com with ESMTPSA id p3sm2506353ljj.14.2019.03.14.08.10.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 08:10:15 -0700 (PDT) Subject: Re: [Xen-devel][PATCH] xen/netfront: Remove unneeded .resume callback To: Boris Ostrovsky , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, jgross@suse.com, sstabellini@kernel.org, davem@davemloft.net Cc: Oleksandr Andrushchenko , Volodymyr Babchuk References: <20190314131749.25706-1-andr2000@gmail.com> <6205819a-af39-8cd8-db87-f3fe047ff064@gmail.com> From: Oleksandr Andrushchenko Message-ID: Date: Thu, 14 Mar 2019 17:10:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/14/19 5:02 PM, Boris Ostrovsky wrote: > On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote: >> On 3/14/19 4:47 PM, Boris Ostrovsky wrote: >>> On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote: >>>> From: Oleksandr Andrushchenko >>>> >>>> Currently on driver resume we remove all the network queues and >>>> destroy shared Tx/Rx rings leaving the driver in its current state >>>> and never signaling the backend of this frontend's state change. >>>> This leads to the number of consequences: >>>> - when frontend withdraws granted references to the rings etc. it >>>> cannot >>>>    be cleanly done as the backend still holds those (it was not told to >>>>    free the resources) >>>> - it is not possible to resume driver operation as all the >>>> communication >>>>    means with the backned were destroyed by the frontend, thus >>>>    making the frontend appear to the guest OS as functional, but >>>>    not really. >>> What do you mean? Are you saying that after resume you lose >>> connectivity? >> Exactly, if you take a look at the .resume callback as it is now >> what it does it destroys the rings etc. and never notifies the backend >> of that, e.g. it stays in, say, connected state with communication >> channels destroyed. It never goes into any other Xen bus state, so >> there is >> no way its state machine can help recovering. > > My tree is about a month old so perhaps there is some sort of regression > but this certainly works for me. After resume netfront gets > XenbusStateInitWait from backend which causes xennet_connect(). Ah, the difference can be of the way we get the guest enter the suspend state. I am making my guest to suspend with: echo mem > /sys/power/state And then I use an interrupt to the guest (this is a test code) to wake it up. Could you please share your exact use-case when the guest enters suspend and what you do to resume it? I can see no way backend may want enter XenbusStateInitWait in my use-case as it simply doesn't know we want him to. > > -boris > > Thank you, Oleksandr