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: "Alex Williamson" <alex.williamson@xxxxxx>, "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] alt_itlb_miss?
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 19 Apr 2006 09:05:49 +0800
Delivery-date: Tue, 18 Apr 2006 18:06:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZjPhJdRK7DPko6RBegqpHjTPC3EgADgfaw
Thread-topic: [Xen-ia64-devel] alt_itlb_miss?
>From: Alex Williamson
>Sent: 2006年4月19日 7:16
>
>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,

Yes, that assumption is incorrect. Other example like FPSWA area
may also not be covered by TR entry.

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

So the logic to support identity mapped ITC insertion should be 
added to itlb_miss handler, however the interesting thing is why 
you encounter it in alt_itlb_miss handler. As above debug output, 
the rr7 is also configured with vhpt table enabled...

Thanks,
Kevin

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