From: Jan Beulich <email@example.com> To: "Xia, Hongyan" <firstname.lastname@example.org> Cc: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Gul, Mahircan" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "Ning, Raphael" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Grall, Julien" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: [PATCH RFC 1/2] docs/design: Add a design document for Live Update Date: Fri, 7 May 2021 17:28:49 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On 07.05.2021 16:59, Xia, Hongyan wrote: > On Fri, 2021-05-07 at 14:15 +0200, Jan Beulich wrote: >> On 07.05.2021 13:44, Julien Grall wrote: > [...] >>> >>> It is a known convenient place. It may be difficult to find a >>> similar >>> spot on host that have been long-running. >> >> I'm not convinced: If it was placed in the kexec area at a 2Mb >> boundary, it could just run from there. If the kexec area is >> large enough, this would work any number of times (as occupied >> ranges become available again when the next LU cycle ends). > > To make sure the next Xen can be loaded and run anywhere in case kexec > cannot find large enough memory under 4G, we need to: > > 1. teach kexec to load the whole image contiguously. At the moment > kexec prepares scattered 4K pages which are not runnable until they are > copied to a contiguous destination. (What if it can't find a contiguous > range?) > > 2. teach Xen that it can be jumped into with some existing page tables > which point to itself above 4G. We can't do real/protected mode entry > because it needs to start below 4G physically. Maybe a modified version > of the EFI entry path (my familiarity with Xen EFI entry is limited)? > > 3. rewrite all the early boot bits that assume Xen is under 4G and its > bundled page tables for below 4G. > > These are the obstacles off the top of my head. So I think there is no > fundamental reason why we have to place Xen #2 where Xen #1 was, but > doing so is a massive reduction of pain which allows us to reuse much > of the existing Xen code. > > Maybe, this part does not have to be part of the ABI and we just > suggest this as one way of loading the next Xen to cope with growth? > This is the best way I can think of (loading Xen where it was and > expand into the reserved bootmem if needed) that does not need to > rewrite a lot of early boot code and can pretty much guarantee success > even if memory is tight and fragmented. Yeah, all of this as an initial implementation plan sounds fine to me. But it should then be called out as such (rather than as part of how things ought to [remain to] be). Jan
next prev parent reply other threads:[~2021-05-07 15:29 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-06 10:42 [PATCH RFC 0/2] Add a design document for Live Updating Xen Julien Grall 2021-05-06 10:42 ` [PATCH RFC 1/2] docs/design: Add a design document for Live Update Julien Grall 2021-05-06 14:43 ` Paul Durrant 2021-05-07 9:18 ` Hongyan Xia 2021-05-07 10:00 ` Julien Grall 2021-05-07 9:52 ` Jan Beulich 2021-05-07 11:44 ` Julien Grall 2021-05-07 12:15 ` Jan Beulich 2021-05-07 14:59 ` Xia, Hongyan 2021-05-07 15:28 ` Jan Beulich [this message] 2021-05-06 10:42 ` [PATCH RFC 2/2] xen/kexec: Reserve KEXEC_TYPE_LIVEUPDATE and KEXEC_RANGE_MA_LIVEUPDATE Julien Grall 2021-05-07 7:59 ` Paul Durrant 2021-05-07 8:24 ` Hongyan Xia 2021-05-07 8:30 ` Jan Beulich
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH RFC 1/2] docs/design: Add a design document for Live Update' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).