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

Re: [Xen-ia64-devel] alt_itlb_miss?



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


 


Rackspace

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