[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 25/38] arm: remove old identity map of boot paddr when we are done with it.



On Wed, 2012-06-06 at 19:18 +0100, Tim Deegan wrote:
> At 19:04 +0100 on 06 Jun (1339009473), Stefano Stabellini wrote:
> > On Fri, 1 Jun 2012, Ian Campbell wrote:
> > > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > > ---
> > >  xen/arch/arm/mm.c |    8 ++++++++
> > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > index 160a4e9..ab52171 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -214,6 +214,14 @@ void __init setup_pagetables(unsigned long 
> > > boot_phys_offset)
> > >      lpae_t pte, *p;
> > >      int i;
> > >  
> > > +    if ( boot_phys_offset != 0 )
> > > +    {
> > > +        /* Remove the old identity mapping of the boot paddr */
> > > +        pte.bits = 0;
> > > +        dest_va = (unsigned long)_start + boot_phys_offset;
> > > +        write_pte(xen_second + second_linear_offset(dest_va), pte);
> > > +    }
> > 
> > It looks like we are already doing this few lines below.
> 
> We used to do this here and now we do it futher down, after the copy.
> That way the secondary CPUs can come up on the pre-copy tables where
> the identity map still exists.

I think I wrote this patch before your SMP series went in, but since
there was no textual conflict I didn't notice that I should nuke it.

Hrm... I was about to do the nuking but without it I see:

        At 0x00000000, Error: Pagetable properties were remapped while
        MMU was enabled, may be stale translations

from the model. I use 
        cluster.messages.ignore_warning_level=0x1
in my cfg which I think is a bit more verbose than the default.

I need to re-figure out what lead me to this change...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.