All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>, "Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Varad Gautam" <vrd@amazon.de>,
	paul@xen.org, "Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Hongyan Xia" <hongyxia@amazon.com>, "Amit Shah" <aams@amazon.de>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: [Xen-devel] [RFC PATCH v3 01/22] x86/setup: Don't skip 2MiB underneath relocated Xen image
Date: Thu, 30 Jan 2020 16:13:09 +0000	[thread overview]
Message-ID: <20200130161330.2324143-1-dwmw2@infradead.org> (raw)
In-Reply-To: <a92287c03fed310e08ba40063e370038569b94ac.camel@infradead.org>

From: David Woodhouse <dwmw@amazon.co.uk>

Set 'e' correctly to reflect the location that Xen is actually relocated
to from its default 2MiB location. Not 2MiB below that.

This is only vaguely a bug fix. The "missing" 2MiB would have been used
in the end, and fed to the allocator. It's just that other things don't
get to sit right up *next* to the Xen image, and it isn't very tidy.

For live update, I'd quite like a single contiguous region for the
reserved bootmem and Xen, allowing the 'slack' in the former to be used
when Xen itself grows larger. Let's not allow 2MiB of random heap pages
to get in the way...

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 xen/arch/x86/setup.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d858883404..2677f127b9 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1080,9 +1080,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
             unsigned long pte_update_limit;
 
             /* Select relocation address. */
-            e = end - reloc_size;
-            xen_phys_start = e;
-            bootsym(trampoline_xen_phys_start) = e;
+            xen_phys_start = end - reloc_size;
+            e = xen_phys_start + XEN_IMG_OFFSET;
+            bootsym(trampoline_xen_phys_start) = xen_phys_start;
 
             /*
              * No PTEs pointing above this address are candidates for relocation.
@@ -1090,7 +1090,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
              * and the beginning of region for destination image some PTEs may
              * point to addresses in range [e, e + XEN_IMG_OFFSET).
              */
-            pte_update_limit = PFN_DOWN(e + XEN_IMG_OFFSET);
+            pte_update_limit = PFN_DOWN(e);
 
             /*
              * Perform relocation to new physical address.
@@ -1099,7 +1099,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
              * data until after we have switched to the relocated pagetables!
              */
             barrier();
-            move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1);
+            move_memory(e, XEN_IMG_OFFSET, _end - _start, 1);
 
             /* Walk initial pagetables, relocating page directory entries. */
             pl4e = __va(__pa(idle_pg_table));
-- 
2.21.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-01-30 16:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 16:12 [Xen-devel] [RFC PATCH v3 0/22] Live update: boot memory management, data stream handling, record format David Woodhouse
2020-01-30 16:13 ` David Woodhouse [this message]
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 02/22] x86/boot: Reserve live update boot memory David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 03/22] Reserve live update memory regions David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 04/22] Add KEXEC_RANGE_MA_LIVEUPDATE David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 05/22] Add KEXEC_TYPE_LIVE_UPDATE David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 06/22] Add IND_WRITE64 primitive to kexec kimage David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 07/22] Add basic live update stream creation David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 08/22] Add kimage_add_live_update_data() David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 09/22] Add basic lu_save_all() shell David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 10/22] Don't add bad pages above HYPERVISOR_VIRT_END to the domheap David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 11/22] xen/vmap: allow vm_init_type to be called during early_boot David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 12/22] xen/vmap: allow vmap() to be called during early boot David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 13/22] x86/setup: move vm_init() before end_boot_allocator() David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 14/22] Detect live update breadcrumb at boot and map data stream David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 15/22] Start documenting the live update handover David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 16/22] Migrate migration stream definitions into Xen public headers David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 17/22] Add lu_stream_{open, close, append}_record() David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 18/22] Add LU_VERSION and LU_END records to live update stream David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 19/22] Add shell of lu_reserve_pages() David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 20/22] x86/setup: lift dom0 creation out into create_dom0 function David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 21/22] x86/setup: finish plumbing in live update path through __start_xen() David Woodhouse
2020-01-30 16:13   ` [Xen-devel] [RFC PATCH v3 22/22] x86/setup: simplify handling of initrdidx when no initrd present David Woodhouse
2020-01-31 17:16 ` [Xen-devel] [RFC PATCH v3 23/22] x86/smp: reset x2apic_enabled in smp_send_stop() David Woodhouse
2020-02-18 15:22 ` [Xen-devel] [RFC PATCH v3 0/22] Live update: boot memory management, data stream handling, record format Ian Jackson

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=20200130161330.2324143-1-dwmw2@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=aams@amazon.de \
    --cc=andrew.cooper3@citrix.com \
    --cc=hongyxia@amazon.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=vrd@amazon.de \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.