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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90A97C43381 for ; Thu, 14 Mar 2019 16:33:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 55CAB2077B for ; Thu, 14 Mar 2019 16:33:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pG1CZJNS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727281AbfCNQdf (ORCPT ); Thu, 14 Mar 2019 12:33:35 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:35630 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726971AbfCNQdf (ORCPT ); Thu, 14 Mar 2019 12:33:35 -0400 Received: by mail-lj1-f194.google.com with SMTP id t13so5410591lji.2; Thu, 14 Mar 2019 09:33:33 -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=ztS3gPSOsk91WZ0TgMQi1fhBIKxzKIf95VZeUdLbKwA=; b=pG1CZJNS2ek4wvtl1uuDNEJCBTsRIYWzZIj8uhb8kuDaq555ts86ZKL7Woa+x+SbdS 51q7sgCL3xLPAe9IQCYivG+zx/70eSxb3dEoBzXbYm7sBhEhIjeLTX//Xyozi330FCRz 1inPxN6e3Vmo8HbwxDDLJ46A0pAVkVWsftRVsDh+X5bDZBnBAIiBCx9EDnEtzy6kQaty VInk/1/bD/zOg7NhD6wl7mQKNVBsnjhv+bLI8PFtjedVVZ6I+nNtS7ZmOSMfj3eNoPIq lTZQCTMZANr4l85cZkMh3pMhoC8II8LOporap94YUu92Vd2DnRM0MaotCWDNpowazQPP Iysw== 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=ztS3gPSOsk91WZ0TgMQi1fhBIKxzKIf95VZeUdLbKwA=; b=dz2tgAPLNmk86uVHSRYJmCZ2nae4ra3+fAi2F8Imd64j9olaz1Qpq1CYyoZXbLooEA km/jUU40nyuwdtDuwlJoNwXb/DvBQEyvb6dCnyxkd6sxLY8jksB5W8/3YI5hdYIX805x NklbvuZIH68ut7TbtEN0zZQF79JlzdN3oFPxZcGkxqXKbNwjrlNFuAYdr8oehIPaGuI1 5QXdA1RnHT1jgkbJJnQUmRjQwqPjY8dClYYcUTpqxxitZB4+b0NkmKWNbeJT8w6vuXBp CYwS+/CyoPwKH6yOnm207Gs/wgMcA34DfGJn9fti8sSqlX/qUILKBvjBSypKMic5w/mV 3HXQ== X-Gm-Message-State: APjAAAXOrlzUzZuohYRoUReOJbGSa/6BWV518CF+OlPdMpo23OjpuemM T1z8UObedrlzwLbKb9efise1Ikny X-Google-Smtp-Source: APXvYqzS1af4ExjZJjzNtTf4uh52pCOt/7ongY5m7/hCuhFaaCBJ3lfC8gZfXRpWmK3USi8MB3aDDw== X-Received: by 2002:a2e:811:: with SMTP id 17mr28617088lji.42.1552581212341; Thu, 14 Mar 2019 09:33:32 -0700 (PDT) Received: from [192.168.0.20] (6-25-94-178.pool.ukrtel.net. [178.94.25.6]) by smtp.gmail.com with ESMTPSA id z20sm590317lfh.66.2019.03.14.09.33.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 09:33:31 -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> <09afcdca-258f-e5ca-5c31-b7fd079eb213@oracle.com> From: Oleksandr Andrushchenko Message-ID: <46fe25f2-2db7-496a-cd2c-071cd211ea50@gmail.com> Date: Thu, 14 Mar 2019 18:33:29 +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: <09afcdca-258f-e5ca-5c31-b7fd079eb213@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/14/19 17:40, Boris Ostrovsky wrote: > On 3/14/19 11:10 AM, Oleksandr Andrushchenko wrote: >> 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? > > xl save / xl restore > >> I can see no way backend may want enter XenbusStateInitWait in my >> use-case >> as it simply doesn't know we want him to. > > Yours looks like ACPI path, I don't know how well it was tested TBH. Hm, so it does work for your use-case, but doesn't for mine. What would be the best way forward? 1. Implement .resume properly as, for example, block front does [1] 2. Remove .resume completely: this does work as long as backend doesn't change anything I am still a bit unsure if we really need to re-initialize rings, re-read front's config from Xenstore etc - what changes on backend side are expected when we resume the front driver? > > > -boris Thank you, Oleksandr [1] https://elixir.bootlin.com/linux/v5.0.2/source/drivers/block/xen-blkfront.c#L2072