From: Hongyan Xia <hx242@xen.org>
To: xen-devel@lists.xenproject.org
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
julien@xen.org, "Wei Liu" <wl@xen.org>,
"Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH 07/16] x86/pv: rewrite how building PV dom0 handles domheap mappings
Date: Thu, 30 Apr 2020 21:44:16 +0100 [thread overview]
Message-ID: <f16792ed755f806785cd4c0483e46d9c40d9f82b.1588278317.git.hongyxia@amazon.com> (raw)
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
In-Reply-To: <cover.1588278317.git.hongyxia@amazon.com>
From: Hongyan Xia <hongyxia@amazon.com>
Building a PV dom0 is allocating from the domheap but uses it like the
xenheap. This is clearly wrong. Fix.
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
---
xen/arch/x86/pv/dom0_build.c | 58 ++++++++++++++++++++++++++----------
1 file changed, 43 insertions(+), 15 deletions(-)
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index b052f13462..adaa6afda2 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -309,6 +309,10 @@ int __init dom0_construct_pv(struct domain *d,
l3_pgentry_t *l3tab = NULL, *l3start = NULL;
l2_pgentry_t *l2tab = NULL, *l2start = NULL;
l1_pgentry_t *l1tab = NULL, *l1start = NULL;
+ mfn_t l4start_mfn = INVALID_MFN;
+ mfn_t l3start_mfn = INVALID_MFN;
+ mfn_t l2start_mfn = INVALID_MFN;
+ mfn_t l1start_mfn = INVALID_MFN;
/*
* This fully describes the memory layout of the initial domain. All
@@ -535,6 +539,7 @@ int __init dom0_construct_pv(struct domain *d,
for ( i = 0; i < nr_pages; i++, len -= PAGE_SIZE )
{
void *p = __map_domain_page(page + i);
+
memcpy(p, mfn_to_virt(initrd_mfn + i),
min(len, (unsigned long)PAGE_SIZE));
unmap_domain_page(p);
@@ -610,23 +615,32 @@ int __init dom0_construct_pv(struct domain *d,
v->arch.pv.event_callback_cs = FLAT_COMPAT_KERNEL_CS;
}
+#define UNMAP_MAP_AND_ADVANCE(mfn_var, virt_var, maddr) \
+do { \
+ UNMAP_DOMAIN_PAGE(virt_var); \
+ mfn_var = maddr_to_mfn(maddr); \
+ maddr += PAGE_SIZE; \
+ virt_var = map_domain_page(mfn_var); \
+} while ( false )
+
/* WARNING: The new domain must have its 'processor' field filled in! */
if ( !is_pv_32bit_domain(d) )
{
maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l4_page_table;
- l4start = l4tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+ UNMAP_MAP_AND_ADVANCE(l4start_mfn, l4start, mpt_alloc);
+ l4tab = l4start;
clear_page(l4tab);
- init_xen_l4_slots(l4tab, _mfn(virt_to_mfn(l4start)),
- d, INVALID_MFN, true);
- v->arch.guest_table = pagetable_from_paddr(__pa(l4start));
+ init_xen_l4_slots(l4tab, l4start_mfn, d, INVALID_MFN, true);
+ v->arch.guest_table = pagetable_from_mfn(l4start_mfn);
}
else
{
/* Monitor table already created by switch_compat(). */
- l4start = l4tab = __va(pagetable_get_paddr(v->arch.guest_table));
+ l4start_mfn = pagetable_get_mfn(v->arch.guest_table);
+ l4start = l4tab = map_domain_page(l4start_mfn);
/* See public/xen.h on why the following is needed. */
maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table;
- l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+ UNMAP_MAP_AND_ADVANCE(l3start_mfn, l3start, mpt_alloc);
}
l4tab += l4_table_offset(v_start);
@@ -636,14 +650,16 @@ int __init dom0_construct_pv(struct domain *d,
if ( !((unsigned long)l1tab & (PAGE_SIZE-1)) )
{
maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l1_page_table;
- l1start = l1tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+ UNMAP_MAP_AND_ADVANCE(l1start_mfn, l1start, mpt_alloc);
+ l1tab = l1start;
clear_page(l1tab);
if ( count == 0 )
l1tab += l1_table_offset(v_start);
if ( !((unsigned long)l2tab & (PAGE_SIZE-1)) )
{
maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l2_page_table;
- l2start = l2tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+ UNMAP_MAP_AND_ADVANCE(l2start_mfn, l2start, mpt_alloc);
+ l2tab = l2start;
clear_page(l2tab);
if ( count == 0 )
l2tab += l2_table_offset(v_start);
@@ -653,19 +669,19 @@ int __init dom0_construct_pv(struct domain *d,
{
maddr_to_page(mpt_alloc)->u.inuse.type_info =
PGT_l3_page_table;
- l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
+ UNMAP_MAP_AND_ADVANCE(l3start_mfn, l3start, mpt_alloc);
}
l3tab = l3start;
clear_page(l3tab);
if ( count == 0 )
l3tab += l3_table_offset(v_start);
- *l4tab = l4e_from_paddr(__pa(l3start), L4_PROT);
+ *l4tab = l4e_from_mfn(l3start_mfn, L4_PROT);
l4tab++;
}
- *l3tab = l3e_from_paddr(__pa(l2start), L3_PROT);
+ *l3tab = l3e_from_mfn(l2start_mfn, L3_PROT);
l3tab++;
}
- *l2tab = l2e_from_paddr(__pa(l1start), L2_PROT);
+ *l2tab = l2e_from_mfn(l1start_mfn, L2_PROT);
l2tab++;
}
if ( count < initrd_pfn || count >= initrd_pfn + PFN_UP(initrd_len) )
@@ -692,9 +708,9 @@ int __init dom0_construct_pv(struct domain *d,
if ( !l3e_get_intpte(*l3tab) )
{
maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l2_page_table;
- l2tab = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
- clear_page(l2tab);
- *l3tab = l3e_from_paddr(__pa(l2tab), L3_PROT);
+ UNMAP_MAP_AND_ADVANCE(l2start_mfn, l2start, mpt_alloc);
+ clear_page(l2start);
+ *l3tab = l3e_from_mfn(l2start_mfn, L3_PROT);
}
if ( i == 3 )
l3e_get_page(*l3tab)->u.inuse.type_info |= PGT_pae_xen_l2;
@@ -705,9 +721,17 @@ int __init dom0_construct_pv(struct domain *d,
unmap_domain_page(l2t);
}
+#undef UNMAP_MAP_AND_ADVANCE
+
+ UNMAP_DOMAIN_PAGE(l1start);
+ UNMAP_DOMAIN_PAGE(l2start);
+ UNMAP_DOMAIN_PAGE(l3start);
+
/* Pages that are part of page tables must be read only. */
mark_pv_pt_pages_rdonly(d, l4start, vpt_start, nr_pt_pages);
+ UNMAP_DOMAIN_PAGE(l4start);
+
/* Mask all upcalls... */
for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ )
shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1;
@@ -869,8 +893,12 @@ int __init dom0_construct_pv(struct domain *d,
* !CONFIG_VIDEO case so the logic here can be simplified.
*/
if ( pv_shim )
+ {
+ l4start = map_domain_page(l4start_mfn);
pv_shim_setup_dom(d, l4start, v_start, vxenstore_start, vconsole_start,
vphysmap_start, si);
+ UNMAP_DOMAIN_PAGE(l4start);
+ }
if ( is_pv_32bit_domain(d) )
xlat_start_info(si, pv_shim ? XLAT_start_info_console_domU
--
2.24.1.AMZN
next prev parent reply other threads:[~2020-04-30 20:45 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 20:44 [PATCH 00/16] Remove the direct map Hongyan Xia
2020-04-30 20:44 ` [PATCH 01/16] x86/setup: move vm_init() before acpi calls Hongyan Xia
2020-04-30 20:44 ` [PATCH 02/16] acpi: vmap pages in acpi_os_alloc_memory Hongyan Xia
2020-05-01 12:02 ` Wei Liu
2020-05-01 12:46 ` Hongyan Xia
2020-05-01 21:35 ` Julien Grall
2020-05-04 8:27 ` Hongyan Xia
2020-04-30 20:44 ` [PATCH 03/16] x86/numa: vmap the pages for memnodemap Hongyan Xia
2020-04-30 20:44 ` [PATCH 04/16] x86/srat: vmap the pages for acpi_slit Hongyan Xia
2020-11-30 10:16 ` Jan Beulich
2020-11-30 18:11 ` Hongyan Xia
2020-12-01 7:37 ` Jan Beulich
2020-04-30 20:44 ` [PATCH 05/16] x86: map/unmap pages in restore_all_guests Hongyan Xia
2020-04-30 20:44 ` [PATCH 06/16] x86/pv: domheap pages should be mapped while relocating initrd Hongyan Xia
2020-04-30 20:44 ` Hongyan Xia [this message]
2020-04-30 20:44 ` [PATCH 08/16] x86: add Persistent Map (PMAP) infrastructure Hongyan Xia
2020-04-30 20:44 ` [PATCH 09/16] x86: lift mapcache variable to the arch level Hongyan Xia
2020-04-30 20:44 ` [PATCH 10/16] x86/mapcache: initialise the mapcache for the idle domain Hongyan Xia
2020-04-30 20:44 ` [PATCH 11/16] x86: add a boot option to enable and disable the direct map Hongyan Xia
2020-05-01 8:43 ` Julien Grall
2020-05-01 12:11 ` Wei Liu
2020-05-01 12:59 ` Hongyan Xia
2020-05-01 13:11 ` Wei Liu
2020-05-01 15:59 ` Julien Grall
2020-04-30 20:44 ` [PATCH 12/16] x86/domain_page: remove the fast paths when mfn is not in the directmap Hongyan Xia
2020-04-30 20:44 ` [PATCH 13/16] xen/page_alloc: add a path for xenheap when there is no direct map Hongyan Xia
2020-05-01 8:50 ` Julien Grall
2021-04-22 12:31 ` Jan Beulich
2021-04-28 11:04 ` Hongyan Xia
2021-04-28 11:51 ` Jan Beulich
2021-04-28 13:22 ` Hongyan Xia
2021-04-28 13:55 ` Jan Beulich
2020-04-30 20:44 ` [PATCH 14/16] x86/setup: leave early boot slightly earlier Hongyan Xia
2020-04-30 20:44 ` [PATCH 15/16] x86/setup: vmap heap nodes when they are outside the direct map Hongyan Xia
2020-04-30 20:44 ` [PATCH 16/16] x86/setup: do not create valid mappings when directmap=no Hongyan Xia
2020-05-01 12:07 ` [PATCH 00/16] Remove the direct map Wei Liu
2020-05-01 13:53 ` Hongyan Xia
2020-06-02 9:08 ` Wei Liu
2021-04-28 10:14 ` Hongyan Xia
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=f16792ed755f806785cd4c0483e46d9c40d9f82b.1588278317.git.hongyxia@amazon.com \
--to=hx242@xen.org \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--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.