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-ia64-devel

Re: [Xen-ia64-devel] alt_itlb_miss?

To: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] alt_itlb_miss?
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Tue, 18 Apr 2006 17:15:48 -0600
Delivery-date: Tue, 18 Apr 2006 16:16:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1145398086.4996.28.camel@localhost>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: LOSL
References: <1145398086.4996.28.camel@localhost>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2006-04-18 at 16:08 -0600, Alex Williamson wrote:
> Hi,
> 
>    I know we had some discussion about this back in February, but I'm
> hitting the alt_itlb_miss handler in Xen and blowing up.  The scenario
> where I see this is when the EFI runtime code doesn't happen to be
> covered by the TR inserted for PAL.  The box I have with this slightly
> different, but perfectly valid, address map dies when calling
> efi_gettimeofday().  Back in February, it seemed like we disabled the
> alt_itlb_miss handler thinking that everything would be covered by the
> TRs inserted for the kernel and PAL, but I don't think we considered
> other parts of firmware that might not be in the same granule as PAL.
> It's actually surprising to me that we haven't hit this yet.  Is there
> any reason we should keep the FORCE_CRASH at the end of alt_itlb_miss,
> or can I get rid of it?  Thanks,

   FWIW, here's some more data about the system state when I hit the
FORCE_CRASH in alt_itlb_miss (this is for the case of dom0 doing
efi.get_time via fw_hypercall):

cr.ifa = 0xf00000003ea57570
cr.iip = 0xf00000003ea57570
b0 = 0xf000000004086020 (virt_get_time+0x80)
psr.cpl = 0

rr0 = 0x0000000000100038
rr1 = 0x0000000001000439
rr2 = 0x0000000002000439
rr3 = 0x0000000003000439
rr4 = 0x0000000004000439
rr5 = 0x0000000005000439
rr6 = 0x0000000006000439
rr7 - 0x0000000007000439

The PAL ITR is at 0xf00000003f000000.  The system I'm typically using
has the EFI runtime section covered by the PAL ITR.  Thanks,

        Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab


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