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

RE: [Xen-ia64-devel] Linux bug with Xen


  • To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 23 Mar 2006 20:33:54 +0800
  • Delivery-date: Thu, 23 Mar 2006 12:35:08 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcZOdSFKP3Ji+M9vRAeW4uos64l58wAAF6tA
  • Thread-topic: [Xen-ia64-devel] Linux bug with Xen

>From: Tristan Gingold
>Sent: 2006年3月23日 20:31
>Hi,
>
>I think I hit a linux kernel bug.
>The situation is:
>
>* an interrupt happen
>* interrupt IVT entry is executed with ic=0
>* within the entry, SAVE_MIN_WITH_COVER try to access to the current
>area,
>  pointed by kr6
>* Unfortunatly, the 'current' area is not mapped, thus xen has to handle
>the
>page fault.
>* the translation fails inside Xen and Xen injects a nested dtlb miss fault.
>* The linux nested dtlb miss don't know how to handle this fault (only
>vmemmap
>are handled).
>
>As far as I know/read the sources, the linux current area is not
>TR-mapped.
>So Xen appears to be correct and the linux kernel may be buggy here.

No, the current stack is always mapped by TR (at a granule of 64M/16M), 
or else nothing can be forwarded since heavy weight exception handler 
always needs to save interrupt context to current stack when psr.ic off. 
You can check ia64_switch_to in entry.S, and so that's a Xen bug since 
xen should always hit translation in vTR area.

Thanks,
Kevin

>
>I will try to understand why Xen cannot resolve the page fault.
>
>Comments ?
>
>Tristan.
>
>
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel

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


 


Rackspace

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