[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 77/84] x86: properly (un)map pages in restore_all_guests.
On Thu, Sep 26, 2019 at 10:46:40AM +0100, hongyax@xxxxxxxxxx wrote: > From: Hongyan Xia <hongyax@xxxxxxxxxx> > > Before, it assumed both cr3 could be accessed via a direct map. This is > no longer true. Also, this means we can remove a xenheap mapping hack > we introduced earlier when building the cr3 of dom0. > > Signed-off-by: Hongyan Xia <hongyax@xxxxxxxxxx> > --- > xen/arch/x86/pv/dom0_build.c | 11 +++++------ > xen/arch/x86/x86_64/entry.S | 32 +++++++++++++++++++++++++++++--- > 2 files changed, 34 insertions(+), 9 deletions(-) > > diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c > index 0ec30988b8..202edcaa17 100644 > --- a/xen/arch/x86/pv/dom0_build.c > +++ b/xen/arch/x86/pv/dom0_build.c > @@ -623,9 +623,7 @@ int __init dom0_construct_pv(struct domain *d, > if ( !is_pv_32bit_domain(d) ) > { > maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l4_page_table; > - l4start = l4tab = __va(mpt_alloc); > - map_pages_to_xen((unsigned long)l4start, maddr_to_mfn(mpt_alloc), 1, > - PAGE_HYPERVISOR); > + l4start = l4tab = map_xen_pagetable(maddr_to_mfn(mpt_alloc)); > mpt_alloc += PAGE_SIZE; > clear_page(l4tab); > init_xen_l4_slots(l4tab, _mfn(virt_to_mfn(l4start)), > @@ -635,9 +633,8 @@ int __init dom0_construct_pv(struct domain *d, > else > { > /* Monitor table already created by switch_compat(). */ > - l4start = l4tab = __va(pagetable_get_paddr(v->arch.guest_table)); > - map_pages_to_xen((unsigned long)l4start, > - pagetable_get_mfn(v->arch.guest_table), 1, PAGE_HYPERVISOR); > + l4start = l4tab = > + map_xen_pagetable(pagetable_get_mfn(v->arch.guest_table)); > /* See public/xen.h on why the following is needed. */ > maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table; > l3start = map_xen_pagetable(maddr_to_mfn(mpt_alloc)); > @@ -907,6 +904,8 @@ int __init dom0_construct_pv(struct domain *d, > pv_shim_setup_dom(d, l4start, v_start, vxenstore_start, > vconsole_start, > vphysmap_start, si); > > + UNMAP_XEN_PAGETABLE(l4start); > + These hunks should be part of a previous patch, right? The one you changed PV Dom0 construction. > if ( is_pv_32bit_domain(d) ) > xlat_start_info(si, pv_shim ? XLAT_start_info_console_domU > : XLAT_start_info_console_dom0); > diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S > index 11385857fa..8ca9a8e0ea 100644 > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -150,11 +150,27 @@ restore_all_guest: > je .Lrag_copy_done > movb $0, STACK_CPUINFO_FIELD(root_pgt_changed)(%rdx) > movabs $PADDR_MASK & PAGE_MASK, %rsi > - movabs $DIRECTMAP_VIRT_START, %rcx > and %rsi, %rdi > and %r9, %rsi > - add %rcx, %rdi > - add %rcx, %rsi > + > + /* Without a direct map, we have to map pages first before copying. > */ > + /* FIXME: optimisations may be needed. */ > + pushq %r9 > + pushq %rdx > + pushq %rax > + pushq %rsi > + shr $PAGE_SHIFT, %rdi > + callq map_xen_pagetable > + popq %rdi > + pushq %rax > + shr $PAGE_SHIFT, %rdi > + callq map_xen_pagetable > + mov %rax, %rsi > + mov 0(%rsp), %rdi > + > + /* %rsi and %rdi are on top the stack for unmapping. */ > + pushq %rsi > + > mov $ROOT_PAGETABLE_FIRST_XEN_SLOT, %ecx > mov root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rsi), %r8 > mov %r8, root_table_offset(SH_LINEAR_PT_VIRT_START)*8(%rdi) > @@ -166,6 +182,16 @@ restore_all_guest: > sub $(ROOT_PAGETABLE_FIRST_XEN_SLOT - \ > ROOT_PAGETABLE_LAST_XEN_SLOT - 1) * 8, %rdi > rep movsq > + > + /* Unmap the two pages. */ > + popq %rdi > + callq unmap_xen_pagetable > + popq %rdi > + callq unmap_xen_pagetable > + popq %rax > + popq %rdx > + popq %r9 > + This section is for synchronising root page tables. Now that it has become so long, it would be better if you write a C function for this purpose. Wei. > .Lrag_copy_done: > mov %r9, STACK_CPUINFO_FIELD(xen_cr3)(%rdx) > movb $1, STACK_CPUINFO_FIELD(use_pv_cr3)(%rdx) > -- > 2.17.1 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |