[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 17 Oct 2007 14:43:09 +0100
  • Delivery-date: Wed, 17 Oct 2007 06:43:57 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcgQw6c15d00Gny2EdyDiAAX8io7RQ==
  • Thread-topic: [Xen-devel] Double mapping of iomem assertion

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.

 -- Keir

On 17/10/07 14:25, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:

> We have two drivers that both map a region of IO memory from a PCI
> device.  This works fine on Linux, but in xen dom0 we hit an assertion
> in arch/i386/mm/ioremap-xen.c:direct_remap_area_pte_fn() when doing the
> second ioremap():
> 
>         BUG_ON(!pte_none(*pte));
> 
> It's not clear to me whether this is just an over-eager assertion or if
> this operation is genuinely not supported on Xen.  The assertion doesn't
> seem to be related to the operation of that function, and if I remove it
> everything seems to work fine.
> 
> Is anyone who is more familiar with this code able to throw any light on
> the reason for the assertion?
> 
> Thanks
> 
> Kieran
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.