Re: [Xen-devel] [PATCH 1/6] xen/arm: introduce map_phys_range

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 6 Dec 2012, Ian Campbell wrote:
> On Wed, 2012-12-05 at 18:19 +0000, Stefano Stabellini wrote:
> > Introduce a function to map a physical memory into virtual memory.
> > It is going to be used later to map the videoram.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > ---
> >  xen/arch/arm/mm.c        |   23 +++++++++++++++++++++++
> >  xen/include/asm-arm/mm.h |    3 +++
> >  2 files changed, 26 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > index 68ee9da..418a414 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -376,6 +376,29 @@ void __init setup_frametable_mappings(paddr_t ps, 
> > paddr_t pe)
> >      frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * 
> > sizeof(struct page_info));
> >  }
> >  
> > +/* Map the physical memory range start -  end at the virtual address
> > + * virt_start in 2MB chunks. start and virt_start have to be 2MB
> > + * aligned.
> > + */
> > +void map_phys_range(paddr_t start, paddr_t end,
> > +        unsigned long virt_start, unsigned attributes)
> > +{
> > +    ASSERT(!(start & ((1 << 21) - 1)));
> > +    ASSERT(!(virt_start & ((1 << 21) - 1)));
> > +
> > +    while ( start < end )
> > +    {
> > +        lpae_t e = mfn_to_xen_entry(start >> PAGE_SHIFT);
> > +        e.pt.ai = attributes;
> > +        write_pte(xen_second + second_table_offset(virt_start), e);
> > +        
> > +        start += (1<<21);
> > +        virt_start += (1<<21);
> > +    }
> > +
> > +    flush_xen_data_tlb();
> 
> What does this flush? The ptes are flushed by the write_pte aren't they?

write_pte doesn't flush the tlb at the moment.

> Should this be a range over virt_start + len?

Yes, ideally it would flush only the range virt_start-virt_start+size.
In practice I think I could remove the flush entirely because we don't
have any previous mappings at virt_start but I presume that it is not a
good idea to rely on that?

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