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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 B0B1EC433ED for ; Tue, 18 May 2021 09:18:57 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4BF606135B for ; Tue, 18 May 2021 09:18:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4BF606135B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=invisiblethingslab.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.128975.242099 (Exim 4.92) (envelope-from ) id 1livsC-0003sk-3p; Tue, 18 May 2021 09:18:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 128975.242099; Tue, 18 May 2021 09:18:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1livsC-0003sd-0k; Tue, 18 May 2021 09:18:44 +0000 Received: by outflank-mailman (input) for mailman id 128975; Tue, 18 May 2021 09:18:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1livsA-0003sX-AI for xen-devel@lists.xenproject.org; Tue, 18 May 2021 09:18:42 +0000 Received: from out5-smtp.messagingengine.com (unknown [66.111.4.29]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ef05ad80-2aa8-4b33-8dec-7acfe4a62890; Tue, 18 May 2021 09:18:40 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B75B05C01C6; Tue, 18 May 2021 05:18:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 18 May 2021 05:18:40 -0400 Received: from mail-itl (ip5b434f04.dynamic.kabel-deutschland.de [91.67.79.4]) by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 May 2021 05:18:38 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ef05ad80-2aa8-4b33-8dec-7acfe4a62890 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=pQOEY9 uzaBbBGayfBBHGueQpT/CjFd/DrtGtIFRgTjc=; b=O7+4JlrellB3ex6Fnt9+Ge D/TTpy0wedSr9jVAKUZLwrrmKzob4xubqRF00xZRHC35wvgyVTKvF43lg7A7rmCF eeypZyImb6/S8K5I93ous5ioW3PjhKegRNyU5vHYjSSCDD/R6+zvYPtjBEE9mLDd BCifk+9YlM4g6GmI5lEJCVyByaQgwvbMGxtqHEKW8gqtTy9bGUEe+YkXEmRAXT6W 6ExJE42kTGpz5vHh6DUh2gRVBgRHwWi6FJ5SML+cjyHKyMoP08jzvgZERv0AowTq z0Wo+99T+9KNcCmjjNiQxPctiP7cbBc2ilUOzbOdSHTS7pmD2AYs1W+1JeRKiZBw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeijedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtdorredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeiieeh jeegteeggeeigffhkeekieefjeduhedvfffhiefgkefhvdevfeejffdvfeenucfkpheple durdeijedrjeelrdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtg homh X-ME-Proxy: Date: Tue, 18 May 2021 11:18:35 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: paul@xen.org Cc: "Durrant, Paul" , Michael Brown , "xen-devel@lists.xenproject.org" , "netdev@vger.kernel.org" , "wei.liu@kernel.org" , Ian Jackson , Wei Liu , Anthony PERARD Subject: Re: [PATCH] xen-netback: Check for hotplug-status existence before watching Message-ID: References: <404130e4-210d-2214-47a8-833c0463d997@fensystems.co.uk> <21f38a92-c8ae-12a7-f1d8-50810c5eb088@fensystems.co.uk> <9edd6873034f474baafd70b1df693001@EX13D32EUC003.ant.amazon.com> <8b7a9cd5-3696-65c2-5656-a1c8eb174344@xen.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f87/K/rmaC2eIhg2" Content-Disposition: inline In-Reply-To: <8b7a9cd5-3696-65c2-5656-a1c8eb174344@xen.org> --f87/K/rmaC2eIhg2 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2021 11:18:35 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: paul@xen.org Cc: "Durrant, Paul" , Michael Brown , "xen-devel@lists.xenproject.org" , "netdev@vger.kernel.org" , "wei.liu@kernel.org" , Ian Jackson , Wei Liu , Anthony PERARD Subject: Re: [PATCH] xen-netback: Check for hotplug-status existence before watching On Tue, May 18, 2021 at 07:57:16AM +0100, Paul Durrant wrote: > On 17/05/2021 22:43, Marek Marczykowski-G=C3=B3recki wrote: > > On Tue, May 11, 2021 at 12:46:38PM +0000, Durrant, Paul wrote: > > > I really can't remember any detail. Perhaps try reverting both patche= s then and check that the unbind/rmmod/modprobe/bind sequence still works (= and the backend actually makes it into connected state). > >=20 > > Ok, I've tried this. I've reverted both commits, then used your test > > script from the 9476654bd5e8ad42abe8ee9f9e90069ff8e60c17: > > This has been tested by running iperf as a server in the test VM a= nd > > then running a client against it in a continuous loop, whilst also > > running: > > while true; > > do echo vif-$DOMID-$VIF >unbind; > > echo down; > > rmmod xen-netback; > > echo unloaded; > > modprobe xen-netback; > > cd $(pwd); > > brctl addif xenbr0 vif$DOMID.$VIF; > > ip link set vif$DOMID.$VIF up; > > echo up; > > sleep 5; > > done > > in dom0 from /sys/bus/xen-backend/drivers/vif to continuously unbi= nd, > > unload, re-load, re-bind and re-plumb the backend. > > In fact, the need to call `brctl` and `ip link` manually is exactly > > because the hotplug script isn't executed. When I execute it manually, > > the backend properly gets back to working. So, removing 'hotplug-status' > > was in the correct place (netback_remove). The missing part is the tool= stack > > calling the hotplug script on xen-netback re-bind. > >=20 >=20 > Why is that missing? We're going behind the back of the toolstack to do t= he > unbind and bind so why should we expect it to re-execute a hotplug script? Ok, then simply execute the whole hotplug script (instead of its subset) after re-loading the backend module and everything will be fine. For example like this: XENBUS_PATH=3Dbackend/vif/$DOMID/$VIF \ XENBUS_TYPE=3Dvif \ XENBUS_BASE_PATH=3Dbackend \ script=3D/etc/xen/scripts/vif-bridge \ vif=3Dvif.$DOMID.$VIF \ /etc/xen/scripts/vif-bridge online (...) > > In short: if device gets XenbusStateInitWait for the first time (ddev = =3D=3D > > NULL case), it goes to add_device() which executes the hotplug script > > and stores the device. > > Then, if device goes to XenbusStateClosed + online=3D=3D0 state, then it > > executes hotplug script again (with "offline" parameter) and forgets the > > device. If you unbind the driver, the device stays in > > XenbusStateConnected state (in xenstore), and after you bind it again, > > it goes to XenbusStateInitWait. It don't think it goes through > > XenbusStateClosed, and online stays at 1 too, so libxl doesn't execute > > the hotplug script again. >=20 > This is pretty key. The frontend should not notice an unbind/bind i.e. th= ere > should be no evidence of it happening by examining states in xenstore (fr= om > the guest side). If you update the backend module, I think the frontend needs at least to re-evaluate feature-* nodes. In case of applying just a bug fix, they should not change (in theory), but technically that would be the correct thing to do. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --f87/K/rmaC2eIhg2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmCjhmsACgkQ24/THMrX 1yx8oAf/XCZOI2Ckmb3Ii8u0x2jWgKb9lUQJOhjXf1KjxF5xkUaM0EGGflO20D3h VuobCUFcsEsrjBqJkaKT3mST0yYVyQzQhGerIVEn46UulxekbclZUCfhVylqi4ft epRzNdTuENg9Rdsb5j7DL2/pq/LVTdOdK5r0En8vXE903YK6ylYj1zlnAl4L5hGP kDQpRXZZpvvGzCynS6QrIsN3amJY4i+gq4C/WHZzzVBQPbFy2rnDTjlCljaBfd0v /xA4eoYvJpcg6ia1O5JAKG34sD9I9PeFsY/A+6shzghDe+5L5R/CBCBwU4XNVKg6 wJPOcMJyZijDHT1jacYGybor/WxeoA== =gEzQ -----END PGP SIGNATURE----- --f87/K/rmaC2eIhg2--