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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 398C1C433EF for ; Thu, 6 Jan 2022 16:59:38 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.254179.435778 (Exim 4.92) (envelope-from ) id 1n5W6f-00011y-TP; Thu, 06 Jan 2022 16:59:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 254179.435778; Thu, 06 Jan 2022 16:59:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1n5W6f-00011r-Q7; Thu, 06 Jan 2022 16:59:17 +0000 Received: by outflank-mailman (input) for mailman id 254179; Thu, 06 Jan 2022 16:59:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1n5W6d-00011h-EE for xen-devel@lists.xenproject.org; Thu, 06 Jan 2022 16:59:15 +0000 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f74ce459-6f11-11ec-9ce5-af14b9085ebd; Thu, 06 Jan 2022 17:59:12 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id CF91A3203661; Thu, 6 Jan 2022 11:59:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 06 Jan 2022 11:59:08 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 6 Jan 2022 11:59:05 -0500 (EST) 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: f74ce459-6f11-11ec-9ce5-af14b9085ebd 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=fm1; bh=0vGvuv juDyt65yvtD1GJB2V8OzoYjUroXY3LcTsJRBA=; b=AJU/XMZPfjlQwqtfnQH9Kp 9iQBSyqhKuVR6g1HxAKZtdQ/2GZIRuKEXQaGlTF6BWlbFaxQBylyzF+4C7wGX//H AAyg9C/fNCAdcFHdA9P97dzVWZKGVsqeYc2n3wUERI4QAslmGwZ4eOqpLelYowWN 7GUUPJ6IFu9fbwRDaknxmBAmv3oF87aOBcmD4qwjZUVjzqfKRpWE0sFxuetYgYaU G0C56fBvjYxjMhCGzyBYqEgKL4i2DRGESPJeKnYAESfI6G7oDWr9MkDdehGyoj1K jSueILlbmoSc9mO0pa0hqFh8rOPWnWKUVpbdDnc4dgKmKZcE7S/ghu+unRiC+UaQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefledgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeetveff iefghfekhffggeeffffhgeevieektedthfehveeiheeiiedtudegfeetffenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Date: Thu, 6 Jan 2022 17:59:03 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Juergen Gross Cc: "xen-devel@lists.xenproject.org" , Julien Grall , Jan Beulich , Andrew Cooper , George Dunlap , Ian Jackson , Anthony PERARD , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Re: Live update of Xenstore-stubdom Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a0uNv+m80abC6JxE" Content-Disposition: inline In-Reply-To: --a0uNv+m80abC6JxE Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2022 17:59:03 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Juergen Gross Cc: "xen-devel@lists.xenproject.org" , Julien Grall , Jan Beulich , Andrew Cooper , George Dunlap , Ian Jackson , Anthony PERARD , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Re: Live update of Xenstore-stubdom On Thu, Jan 06, 2022 at 03:33:49PM +0100, Juergen Gross wrote: > I'm currently thinking how to implement live update of Xenstore-stubdom. >=20 > I should note that my plan is to support live update for a Xenstore PVH > stubdom only, as kexec functionality is much easier to implement for > that case. >=20 > The main problem is to transfer the Xenstore state to the new instance. >=20 > Originally my idea was to keep the state in memory and hand it over to > the new kernel as a module. This would probably work, but there is one > basic problem with that approach: the Xenstore domain might need quite > some additional memory to hold the module (roughly up to twice the > memory it has in use when starting the live update). >=20 > As a result the live update sequence would need to: >=20 > 1. increase the maximum allowed memory of the Xenstore domain > 2. allocate additional memory for the module > 3. create the module > 4. kexec to the new kernel > 5. build the Xenstore from the module > 6. free the module memory > 7. decrease the max memory of the domain again >=20 > The first and last step would need to be done by xenstore-control in > dom0, while all the other steps would be done in the Xenstore-stubdom. >=20 > As an alternative I was thinking to add some basic file operations to > Xenstore-stubdom. This would have the additional benefit of having an > easy way to add Xenstore logging support to the stubdom without the risk > to lose logging data when using the console for that purpose. What specifically is wrong about using console for logging? Rate limits? > So what are the thoughts for the way to go with Xenstore-stubdom live > update? Should I use stubdom memory for the state, or should I go with a > file based approach (and if yes, 9pfs or pvcalls based)? Personally, I'd go with memory, as IMHO it the cleanest design from disaggregation point of view (what was in stubomain, remains in stubdomain, no extra external interface necessary). --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --a0uNv+m80abC6JxE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmHXH9YACgkQ24/THMrX 1yxBqQf/R+xOKA4SAt7+X07JsFPxrGMFMHQw7jqaU99Swx8+Ul8+2UT5meQPg71H jq8japwTOBeAB/l74qJM3OvGRUxERdF7JbDCSuZDEqrmSyww0Uydg23GusqNez5I J5NNSllOSJH3Ojjxtnq19YhOPoBEyDdpyQ+Aozlz1ysmMcbNjdXUN25lgOUB8ZTY AW3+Jm0oG2vjtI8r8a+7sF99GRuHwZjRcfH5p3Ysi19zEYKoK7FWeQ93vPfT6305 DfTSqn/1Fc07vBAoJgPnYJ+zZ7Xtewd98xC0jxTSMKVnHlN25LeyLo6+J30t7kTU 35LOKhCVw4I7AK9rRS7JZ5/VcrxetA== =/5IL -----END PGP SIGNATURE----- --a0uNv+m80abC6JxE--