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: Wed, 17 Oct 2007 16:58:55 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 17 Oct 2007 08:59:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C33BCFFD.16F96%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: <C33BCFFD.16F96%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2007-10-17 at 14:43 +0100, Keir Fraser wrote:
> There's no TLB flush or INVLPG, so there is a risk of a stale TLB entry if
> the pte is already in use (we do not consider the case where the pte is
> actually being set to its existing value -- we don't expect that should ever
> happen). If the drivers are using ioremap() then they should be getting
> different virtual addresses and hence no pte overlap, I would have thought.

OK, I've dug a bit deeper.  The problem is not with two mappings of the
same IO region, it is with anything involving ioremap() followed by
iounmap() followed by another ioremap().  I've been able to demonstrate
this by mapping in a region, immediately unmapping it using iounmap(),
then mapping it in again (in this particular case using ioremap_nocache
())

i.e.:
membase = ioremap_nocache ( membase_phys, membase_len );
if ( !membase ) {
        return -ENOMEM;
}

iounmap(membase);

membase = ioremap_nocache ( membase_phys, membase_len );

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.

Kieran


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