Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Xen: Devel

[PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early

 

 

Xen devel RSS feed   Index | Next | Previous | View Threaded


konrad.wilk at oracle

Aug 16, 2012, 9:03 AM

Post #1 of 10 (127 views)
Permalink
[PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early

B/c we do not need it. During the startup the Xen provides
us with all the memory mapped that we need to function.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
---
arch/x86/xen/mmu.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 7247e5a..a59070b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -84,6 +84,7 @@
*/
DEFINE_SPINLOCK(xen_reservation_lock);

+#ifdef CONFIG_X86_32
/*
* Identity map, in addition to plain kernel map. This needs to be
* large enough to allocate page table pages to allocate the rest.
@@ -91,7 +92,7 @@ DEFINE_SPINLOCK(xen_reservation_lock);
*/
#define LEVEL1_IDENT_ENTRIES (PTRS_PER_PTE * 4)
static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);
-
+#endif
#ifdef CONFIG_X86_64
/* l3 pud for userspace vsyscall mapping */
static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
@@ -1628,7 +1629,7 @@ static void set_page_prot(void *addr, pgprot_t prot)
if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
BUG();
}
-
+#ifdef CONFIG_X86_32
static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
{
unsigned pmdidx, pteidx;
@@ -1679,7 +1680,7 @@ static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)

set_page_prot(pmd, PAGE_KERNEL_RO);
}
-
+#endif
void __init xen_setup_machphys_mapping(void)
{
struct xen_machphys_mapping mapping;
@@ -1765,14 +1766,12 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
/* Note that we don't do anything with level1_fixmap_pgt which
* we don't need. */

- /* Set up identity map */
- xen_map_identity_early(level2_ident_pgt, max_pfn);
-
/* Make pagetable pieces RO */
set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
+ set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);

--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


stefano.stabellini at eu

Aug 17, 2012, 10:41 AM

Post #2 of 10 (120 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Thu, 16 Aug 2012, Konrad Rzeszutek Wilk wrote:
> B/c we do not need it. During the startup the Xen provides
> us with all the memory mapped that we need to function.

Shouldn't we check to make sure that is actually true (I am thinking at
nr_pt_frames)?
Or is it actually stated somewhere in the Xen headers?



> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
> ---
> arch/x86/xen/mmu.c | 11 +++++------
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 7247e5a..a59070b 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -84,6 +84,7 @@
> */
> DEFINE_SPINLOCK(xen_reservation_lock);
>
> +#ifdef CONFIG_X86_32
> /*
> * Identity map, in addition to plain kernel map. This needs to be
> * large enough to allocate page table pages to allocate the rest.
> @@ -91,7 +92,7 @@ DEFINE_SPINLOCK(xen_reservation_lock);
> */
> #define LEVEL1_IDENT_ENTRIES (PTRS_PER_PTE * 4)
> static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);
> -
> +#endif
> #ifdef CONFIG_X86_64
> /* l3 pud for userspace vsyscall mapping */
> static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
> @@ -1628,7 +1629,7 @@ static void set_page_prot(void *addr, pgprot_t prot)
> if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
> BUG();
> }
> -
> +#ifdef CONFIG_X86_32
> static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
> {
> unsigned pmdidx, pteidx;
> @@ -1679,7 +1680,7 @@ static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
>
> set_page_prot(pmd, PAGE_KERNEL_RO);
> }
> -
> +#endif
> void __init xen_setup_machphys_mapping(void)
> {
> struct xen_machphys_mapping mapping;
> @@ -1765,14 +1766,12 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
> /* Note that we don't do anything with level1_fixmap_pgt which
> * we don't need. */
>
> - /* Set up identity map */
> - xen_map_identity_early(level2_ident_pgt, max_pfn);
> -
> /* Make pagetable pieces RO */
> set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
> set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
> set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
> set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
> + set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
> set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
> set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);
>
> --
> 1.7.7.6
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel [at] lists
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


konrad.wilk at oracle

Aug 17, 2012, 10:45 AM

Post #3 of 10 (120 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Fri, Aug 17, 2012 at 06:41:23PM +0100, Stefano Stabellini wrote:
> On Thu, 16 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > B/c we do not need it. During the startup the Xen provides
> > us with all the memory mapped that we need to function.
>
> Shouldn't we check to make sure that is actually true (I am thinking at
> nr_pt_frames)?

I was looking at the source code (hypervisor) to figure it out and
that is certainly true.


> Or is it actually stated somewhere in the Xen headers?

Couldn't find it, but after looking so long at the source code
I didn't even bother looking for it.

Thought to be honest - I only looked at how the 64-bit pagetables
were set up, so I didn't dare to touch the 32-bit. Hence the #ifdef

>
>
>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
> > ---
> > arch/x86/xen/mmu.c | 11 +++++------
> > 1 files changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index 7247e5a..a59070b 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -84,6 +84,7 @@
> > */
> > DEFINE_SPINLOCK(xen_reservation_lock);
> >
> > +#ifdef CONFIG_X86_32
> > /*
> > * Identity map, in addition to plain kernel map. This needs to be
> > * large enough to allocate page table pages to allocate the rest.
> > @@ -91,7 +92,7 @@ DEFINE_SPINLOCK(xen_reservation_lock);
> > */
> > #define LEVEL1_IDENT_ENTRIES (PTRS_PER_PTE * 4)
> > static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);
> > -
> > +#endif
> > #ifdef CONFIG_X86_64
> > /* l3 pud for userspace vsyscall mapping */
> > static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
> > @@ -1628,7 +1629,7 @@ static void set_page_prot(void *addr, pgprot_t prot)
> > if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
> > BUG();
> > }
> > -
> > +#ifdef CONFIG_X86_32
> > static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
> > {
> > unsigned pmdidx, pteidx;
> > @@ -1679,7 +1680,7 @@ static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
> >
> > set_page_prot(pmd, PAGE_KERNEL_RO);
> > }
> > -
> > +#endif
> > void __init xen_setup_machphys_mapping(void)
> > {
> > struct xen_machphys_mapping mapping;
> > @@ -1765,14 +1766,12 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
> > /* Note that we don't do anything with level1_fixmap_pgt which
> > * we don't need. */
> >
> > - /* Set up identity map */
> > - xen_map_identity_early(level2_ident_pgt, max_pfn);
> > -
> > /* Make pagetable pieces RO */
> > set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
> > set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
> > set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
> > set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
> > + set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
> > set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
> > set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);
> >
> > --
> > 1.7.7.6
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel [at] lists
> > http://lists.xen.org/xen-devel
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


stefano.stabellini at eu

Aug 20, 2012, 4:45 AM

Post #4 of 10 (121 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Fri, 17 Aug 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 17, 2012 at 06:41:23PM +0100, Stefano Stabellini wrote:
> > On Thu, 16 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > B/c we do not need it. During the startup the Xen provides
> > > us with all the memory mapped that we need to function.
> >
> > Shouldn't we check to make sure that is actually true (I am thinking at
> > nr_pt_frames)?
>
> I was looking at the source code (hypervisor) to figure it out and
> that is certainly true.
>
>
> > Or is it actually stated somewhere in the Xen headers?
>
> Couldn't find it, but after looking so long at the source code
> I didn't even bother looking for it.
>
> Thought to be honest - I only looked at how the 64-bit pagetables
> were set up, so I didn't dare to touch the 32-bit. Hence the #ifdef

I think that we need to involve some Xen maintainers and get this
written down somewhere in the public headers, otherwise we have no
guarantees that it is going to stay as it is in the next Xen versions.

Maybe we just need to add a couple of lines of comment to
xen/include/public/xen.h.

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


Ian.Campbell at citrix

Aug 20, 2012, 4:53 AM

Post #5 of 10 (122 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Mon, 2012-08-20 at 12:45 +0100, Stefano Stabellini wrote:
> On Fri, 17 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > On Fri, Aug 17, 2012 at 06:41:23PM +0100, Stefano Stabellini wrote:
> > > On Thu, 16 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > > B/c we do not need it. During the startup the Xen provides
> > > > us with all the memory mapped that we need to function.
> > >
> > > Shouldn't we check to make sure that is actually true (I am thinking at
> > > nr_pt_frames)?
> >
> > I was looking at the source code (hypervisor) to figure it out and
> > that is certainly true.
> >
> >
> > > Or is it actually stated somewhere in the Xen headers?
> >
> > Couldn't find it, but after looking so long at the source code
> > I didn't even bother looking for it.
> >
> > Thought to be honest - I only looked at how the 64-bit pagetables
> > were set up, so I didn't dare to touch the 32-bit. Hence the #ifdef
>
> I think that we need to involve some Xen maintainers and get this
> written down somewhere in the public headers, otherwise we have no
> guarantees that it is going to stay as it is in the next Xen versions.
>
> Maybe we just need to add a couple of lines of comment to
> xen/include/public/xen.h.

The start of day memory layout for PV guests is written down in the
comment just before struct start_info at
http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_start_info

(I haven't read this thread to determine if what is documented matches
what you guys are talking about relying on)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


stefano.stabellini at eu

Aug 20, 2012, 4:58 AM

Post #6 of 10 (121 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Mon, 20 Aug 2012, Ian Campbell wrote:
> On Mon, 2012-08-20 at 12:45 +0100, Stefano Stabellini wrote:
> > On Fri, 17 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Aug 17, 2012 at 06:41:23PM +0100, Stefano Stabellini wrote:
> > > > On Thu, 16 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > > > B/c we do not need it. During the startup the Xen provides
> > > > > us with all the memory mapped that we need to function.
> > > >
> > > > Shouldn't we check to make sure that is actually true (I am thinking at
> > > > nr_pt_frames)?
> > >
> > > I was looking at the source code (hypervisor) to figure it out and
> > > that is certainly true.
> > >
> > >
> > > > Or is it actually stated somewhere in the Xen headers?
> > >
> > > Couldn't find it, but after looking so long at the source code
> > > I didn't even bother looking for it.
> > >
> > > Thought to be honest - I only looked at how the 64-bit pagetables
> > > were set up, so I didn't dare to touch the 32-bit. Hence the #ifdef
> >
> > I think that we need to involve some Xen maintainers and get this
> > written down somewhere in the public headers, otherwise we have no
> > guarantees that it is going to stay as it is in the next Xen versions.
> >
> > Maybe we just need to add a couple of lines of comment to
> > xen/include/public/xen.h.
>
> The start of day memory layout for PV guests is written down in the
> comment just before struct start_info at
> http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_start_info
>
> (I haven't read this thread to determine if what is documented matches
> what you guys are talking about relying on)

but it is not written down how much physical memory is going to be
mapped in the bootstrap page tables.

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


konrad.wilk at oracle

Aug 20, 2012, 5:06 AM

Post #7 of 10 (123 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Mon, Aug 20, 2012 at 12:58:37PM +0100, Stefano Stabellini wrote:
> On Mon, 20 Aug 2012, Ian Campbell wrote:
> > On Mon, 2012-08-20 at 12:45 +0100, Stefano Stabellini wrote:
> > > On Fri, 17 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Aug 17, 2012 at 06:41:23PM +0100, Stefano Stabellini wrote:
> > > > > On Thu, 16 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > > > > B/c we do not need it. During the startup the Xen provides
> > > > > > us with all the memory mapped that we need to function.
> > > > >
> > > > > Shouldn't we check to make sure that is actually true (I am thinking at
> > > > > nr_pt_frames)?
> > > >
> > > > I was looking at the source code (hypervisor) to figure it out and
> > > > that is certainly true.
> > > >
> > > >
> > > > > Or is it actually stated somewhere in the Xen headers?
> > > >
> > > > Couldn't find it, but after looking so long at the source code
> > > > I didn't even bother looking for it.
> > > >
> > > > Thought to be honest - I only looked at how the 64-bit pagetables
> > > > were set up, so I didn't dare to touch the 32-bit. Hence the #ifdef
> > >
> > > I think that we need to involve some Xen maintainers and get this
> > > written down somewhere in the public headers, otherwise we have no
> > > guarantees that it is going to stay as it is in the next Xen versions.
> > >
> > > Maybe we just need to add a couple of lines of comment to
> > > xen/include/public/xen.h.
> >
> > The start of day memory layout for PV guests is written down in the
> > comment just before struct start_info at
> > http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_start_info
> >
> > (I haven't read this thread to determine if what is documented matches
> > what you guys are talking about relying on)
>
> but it is not written down how much physical memory is going to be
> mapped in the bootstrap page tables.

Considering that only pvops kernel has this change I think we are ok?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel [at] lists
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


stefano.stabellini at eu

Aug 20, 2012, 5:19 AM

Post #8 of 10 (123 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Mon, 20 Aug 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Aug 20, 2012 at 12:58:37PM +0100, Stefano Stabellini wrote:
> > On Mon, 20 Aug 2012, Ian Campbell wrote:
> > > On Mon, 2012-08-20 at 12:45 +0100, Stefano Stabellini wrote:
> > > > On Fri, 17 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > > > On Fri, Aug 17, 2012 at 06:41:23PM +0100, Stefano Stabellini wrote:
> > > > > > On Thu, 16 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > > > > > B/c we do not need it. During the startup the Xen provides
> > > > > > > us with all the memory mapped that we need to function.
> > > > > >
> > > > > > Shouldn't we check to make sure that is actually true (I am thinking at
> > > > > > nr_pt_frames)?
> > > > >
> > > > > I was looking at the source code (hypervisor) to figure it out and
> > > > > that is certainly true.
> > > > >
> > > > >
> > > > > > Or is it actually stated somewhere in the Xen headers?
> > > > >
> > > > > Couldn't find it, but after looking so long at the source code
> > > > > I didn't even bother looking for it.
> > > > >
> > > > > Thought to be honest - I only looked at how the 64-bit pagetables
> > > > > were set up, so I didn't dare to touch the 32-bit. Hence the #ifdef
> > > >
> > > > I think that we need to involve some Xen maintainers and get this
> > > > written down somewhere in the public headers, otherwise we have no
> > > > guarantees that it is going to stay as it is in the next Xen versions.
> > > >
> > > > Maybe we just need to add a couple of lines of comment to
> > > > xen/include/public/xen.h.
> > >
> > > The start of day memory layout for PV guests is written down in the
> > > comment just before struct start_info at
> > > http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_start_info
> > >
> > > (I haven't read this thread to determine if what is documented matches
> > > what you guys are talking about relying on)
> >
> > but it is not written down how much physical memory is going to be
> > mapped in the bootstrap page tables.
>
> Considering that only pvops kernel has this change I think we are ok?

We are OK if we write it down :)
Otherwise it might change in the future and we won't even know what the
correct behavior is supposed to be.

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


konrad.wilk at oracle

Aug 23, 2012, 8:40 AM

Post #9 of 10 (112 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Mon, Aug 20, 2012 at 12:58:37PM +0100, Stefano Stabellini wrote:
> On Mon, 20 Aug 2012, Ian Campbell wrote:
> > On Mon, 2012-08-20 at 12:45 +0100, Stefano Stabellini wrote:
> > > On Fri, 17 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Aug 17, 2012 at 06:41:23PM +0100, Stefano Stabellini wrote:
> > > > > On Thu, 16 Aug 2012, Konrad Rzeszutek Wilk wrote:
> > > > > > B/c we do not need it. During the startup the Xen provides
> > > > > > us with all the memory mapped that we need to function.
> > > > >
> > > > > Shouldn't we check to make sure that is actually true (I am thinking at
> > > > > nr_pt_frames)?
> > > >
> > > > I was looking at the source code (hypervisor) to figure it out and
> > > > that is certainly true.
> > > >
> > > >
> > > > > Or is it actually stated somewhere in the Xen headers?
> > > >
> > > > Couldn't find it, but after looking so long at the source code
> > > > I didn't even bother looking for it.
> > > >
> > > > Thought to be honest - I only looked at how the 64-bit pagetables
> > > > were set up, so I didn't dare to touch the 32-bit. Hence the #ifdef
> > >
> > > I think that we need to involve some Xen maintainers and get this
> > > written down somewhere in the public headers, otherwise we have no
> > > guarantees that it is going to stay as it is in the next Xen versions.
> > >
> > > Maybe we just need to add a couple of lines of comment to
> > > xen/include/public/xen.h.
> >
> > The start of day memory layout for PV guests is written down in the
> > comment just before struct start_info at
> > http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_start_info
> >
> > (I haven't read this thread to determine if what is documented matches
> > what you guys are talking about relying on)
>
> but it is not written down how much physical memory is going to be
> mapped in the bootstrap page tables.

How about this:


From 43fd7a5d9ecd31c2fc26851523cd4b5f7650fb39 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
Date: Thu, 12 Jul 2012 13:59:36 -0400
Subject: [PATCH] xen/mmu: For 64-bit do not call xen_map_identity_early

B/c we do not need it. During the startup the Xen provides
us with all the initial memory mapped that we need to function.

The initial memory mapped is up to the bootstack, which means
we can reference using __ka up to 4.f):

(from xen/interface/xen.h):

4. This the order of bootstrap elements in the initial virtual region:
a. relocated kernel image
b. initial ram disk [mod_start, mod_len]
c. list of allocated page frames [mfn_list, nr_pages]
d. start_info_t structure [register ESI (x86)]
e. bootstrap page tables [pt_base, CR3 (x86)]
f. bootstrap stack [register ESP (x86)]

(initial ram disk may be ommitted).

[v1: More comments in git commit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
---
arch/x86/xen/mmu.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 7247e5a..a59070b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -84,6 +84,7 @@
*/
DEFINE_SPINLOCK(xen_reservation_lock);

+#ifdef CONFIG_X86_32
/*
* Identity map, in addition to plain kernel map. This needs to be
* large enough to allocate page table pages to allocate the rest.
@@ -91,7 +92,7 @@ DEFINE_SPINLOCK(xen_reservation_lock);
*/
#define LEVEL1_IDENT_ENTRIES (PTRS_PER_PTE * 4)
static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);
-
+#endif
#ifdef CONFIG_X86_64
/* l3 pud for userspace vsyscall mapping */
static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
@@ -1628,7 +1629,7 @@ static void set_page_prot(void *addr, pgprot_t prot)
if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
BUG();
}
-
+#ifdef CONFIG_X86_32
static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
{
unsigned pmdidx, pteidx;
@@ -1679,7 +1680,7 @@ static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)

set_page_prot(pmd, PAGE_KERNEL_RO);
}
-
+#endif
void __init xen_setup_machphys_mapping(void)
{
struct xen_machphys_mapping mapping;
@@ -1765,14 +1766,12 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
/* Note that we don't do anything with level1_fixmap_pgt which
* we don't need. */

- /* Set up identity map */
- xen_map_identity_early(level2_ident_pgt, max_pfn);
-
/* Make pagetable pieces RO */
set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
+ set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);

--
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel


stefano.stabellini at eu

Aug 23, 2012, 8:57 AM

Post #10 of 10 (107 views)
Permalink
Re: [PATCH 06/11] xen/mmu: For 64-bit do not call xen_map_identity_early [In reply to]

On Thu, 23 Aug 2012, Konrad Rzeszutek Wilk wrote:
> >From 43fd7a5d9ecd31c2fc26851523cd4b5f7650fb39 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>
> Date: Thu, 12 Jul 2012 13:59:36 -0400
> Subject: [PATCH] xen/mmu: For 64-bit do not call xen_map_identity_early
>
> B/c we do not need it. During the startup the Xen provides
^ remove the
> us with all the initial memory mapped that we need to function.
>
> The initial memory mapped is up to the bootstack, which means
> we can reference using __ka up to 4.f):

Thanks, that is what I was looking for.

> (from xen/interface/xen.h):
>
> 4. This the order of bootstrap elements in the initial virtual region:
> a. relocated kernel image
> b. initial ram disk [mod_start, mod_len]
> c. list of allocated page frames [mfn_list, nr_pages]
> d. start_info_t structure [register ESI (x86)]
> e. bootstrap page tables [pt_base, CR3 (x86)]
> f. bootstrap stack [register ESP (x86)]
>
> (initial ram disk may be ommitted).
>
> [v1: More comments in git commit]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk [at] oracle>

Acked-by: Stefano Stabellini <stefano.stabellini [at] eu>


> ---
> arch/x86/xen/mmu.c | 11 +++++------
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 7247e5a..a59070b 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -84,6 +84,7 @@
> */
> DEFINE_SPINLOCK(xen_reservation_lock);
>
> +#ifdef CONFIG_X86_32
> /*
> * Identity map, in addition to plain kernel map. This needs to be
> * large enough to allocate page table pages to allocate the rest.
> @@ -91,7 +92,7 @@ DEFINE_SPINLOCK(xen_reservation_lock);
> */
> #define LEVEL1_IDENT_ENTRIES (PTRS_PER_PTE * 4)
> static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);
> -
> +#endif
> #ifdef CONFIG_X86_64
> /* l3 pud for userspace vsyscall mapping */
> static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
> @@ -1628,7 +1629,7 @@ static void set_page_prot(void *addr, pgprot_t prot)
> if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
> BUG();
> }
> -
> +#ifdef CONFIG_X86_32
> static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
> {
> unsigned pmdidx, pteidx;
> @@ -1679,7 +1680,7 @@ static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
>
> set_page_prot(pmd, PAGE_KERNEL_RO);
> }
> -
> +#endif
> void __init xen_setup_machphys_mapping(void)
> {
> struct xen_machphys_mapping mapping;
> @@ -1765,14 +1766,12 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
> /* Note that we don't do anything with level1_fixmap_pgt which
> * we don't need. */
>
> - /* Set up identity map */
> - xen_map_identity_early(level2_ident_pgt, max_pfn);
> -
> /* Make pagetable pieces RO */
> set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
> set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
> set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
> set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
> + set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
> set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
> set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);
>
> --
> 1.7.7.6
>

_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
http://lists.xen.org/xen-devel

Xen devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.