Re: [Xen-devel] Double mapping of iomem assertion

[Kieran Mansley <kmansley@xxxxxxxxxxxxxx>]

On Wed, 2007-10-17 at 17:06 +0100, Keir Fraser wrote:
> On 17/10/07 16:58, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:
> 
> > The second ioremap calls get_vm_area() and happens to be given a region
> > of virtual memory that at least partly overlaps the area that was used
> > for the first one.  As the area was freed by the iounmap() in the middle
> > this seems sensible, but then when it comes to get the PTE for the
> > virtual addresses in the second map, it finds there are entries left
> > over from the first one.
> 
> Well, that's bogus. iounmap() should zap all PTEs via remove_vm_area(). If
> it's not doing so then we have a bug.

Yep.

When iounmap() calls remove_vm_area() it percolates down to
vunmap_pte_range().  This seems to not always succeed: checking that !
pte_none() on the pte at the end of that function occasionally throws up
a warning.  Unsurprisingly this is on the same addresses that later hit
the assertion in direct_remap_area_pte_fn().

The reason that vunmap_pte_range() is failing seems to be due to a
problem in xen/arch/x86/mm.c:do_update_va_mapping() (vunmap_pte_range
calls ptep_get_and_clear which calls HYPERVISOR_update_va_mapping).
This is returning EINVAL because it can't get the l1e from the guest:

    pl1e = guest_map_l1e(v, va, &gl1mfn);

    if ( unlikely(!pl1e || !mod_l1_entry(pl1e, val, gl1mfn)) ) 
        rc = -EINVAL;

guest_map_l1e is returning NULL because of incorrect flag settings on
the l2e:

    /* Check flags that it will be safe to read the l1e */
    if ( (l2e_get_flags(l2e) & (_PAGE_PRESENT | _PAGE_PSE)) 
         != _PAGE_PRESENT )
        return NULL;

It looks to me like neither _PAGE_PRESENT nor _PAGE_PSE is set.  Any
advice about why this might be and how to fix this would be gratefully
received.

Kieran


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel