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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-12-06 at 16:06 +0000, Stefano Stabellini wrote:
> 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.

Oh right, it just flushes the dcache.

> > Should this be a range over virt_start + len?
> 
> Yes, ideally it would flush only the range virt_start-virt_start+size.

Why doesn't it?

> 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?

Better safe than sorry I guess.




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