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 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).