WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Double mapping of iomem assertion
From: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Date: Thu, 18 Oct 2007 15:15:10 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 18 Oct 2007 07:15:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C33BF1AF.16FDA%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C33BF1AF.16FDA%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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