xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Xia, Hongyan" <hongyxia@amazon.com>
To: "jbeulich@suse.com" <jbeulich@suse.com>,
	"julien@xen.org" <julien@xen.org>
Cc: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"Gul, Mahircan" <mahgul@amazon.co.uk>,
	"paul@xen.org" <paul@xen.org>,
	"Ning, Raphael" <raphning@amazon.com>, "wl@xen.org" <wl@xen.org>,
	"iwj@xenproject.org" <iwj@xenproject.org>,
	"Grall, Julien" <jgrall@amazon.co.uk>,
	"george.dunlap@citrix.com" <george.dunlap@citrix.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH RFC 1/2] docs/design: Add a design document for Live Update
Date: Fri, 7 May 2021 14:59:14 +0000	[thread overview]
Message-ID: <28b31476e2044161f94bfd85d1d3c8b2f6dfb806.camel@amazon.com> (raw)
In-Reply-To: <324f10b9-2b1f-ec61-1816-44c960c285f8@suse.com>

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.

Hongyan

  reply	other threads:[~2021-05-07 15:00 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 [this message]
2021-05-07 15:28           ` Jan Beulich
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 \
    --in-reply-to=28b31476e2044161f94bfd85d1d3c8b2f6dfb806.camel@amazon.com \
    --to=hongyxia@amazon.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dwmw2@infradead.org \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=jgrall@amazon.co.uk \
    --cc=julien@xen.org \
    --cc=mahgul@amazon.co.uk \
    --cc=paul@xen.org \
    --cc=raphning@amazon.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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).