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

RE: [Xen-ia64-devel] alt_itlb_miss?


  • To: "Alex Williamson" <alex.williamson@xxxxxx>, "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • 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


 


Rackspace

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