Re: [Xen-devel] [PATCH V3 4/4] arm: allocate per-PCPU domheap pagetable pages

[Tim Deegan <tim@xxxxxxx>]

At 14:04 +0100 on 24 Apr (1366812242), Ian Campbell wrote:
> On Wed, 2013-04-24 at 13:49 +0100, Tim Deegan wrote:
> > At 11:54 +0100 on 24 Apr (1366804441), Ian Campbell wrote:
> > > +    /* Some of these slots may have been used during start of day and/or
> > > +     * relocation. Make sure they are clear now. */
> > > +    memset(this_cpu(xen_dommap), 0, DOMHEAP_SECOND_PAGES*PAGE_SIZE);
> > > +    flush_xen_dcache_va_range(this_cpu(xen_dommap),
> > > +                              DOMHEAP_SECOND_PAGES*PAGE_SIZE);
> > > +}
> > 
> > This is a dcache flush -- do we need flush_xen_data_tlb_range_va()
> > instead (or possibly as well)?
> 
> The reason for this zeroing is really for the benefit of the code in
> map_domain_page which is looking at the present bits to find a free
> slot. I had a crash due to it stumbling over the uninitialised memory in
> the freshly allocated secondary CPUs dommap and figured I should zero
> the boot CPUs one as well.

Ah, right - this is flushing the dommap PTEs.  For some reason I read it
as a flush of the domheap VAs.

> It probably doesn't actually matter that much if the MMU sees stale
> entries here (in the case of the boot CPU they will be valid entries,
> not invalid gunk like on the secondaries). At the point that
> map_domain_page actually puts something useful in here it will do all
> the right flushes (I hope!).

Yep.

> In other words I have a feeling even the flush which is there is not
> strictly necessary. However it is consistent with write_pte, which is
> effectively what the memset is doing.

Understood.  And with that, Acked-by: TIm Deegan <tim@xxxxxxx>

Cheers,

Tim.

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