[Xen-ia64-devel] Re: [patch 00/12] Kexec: EFI Mapping: Take IV

[Simon Horman <horms@xxxxxxxxxxxx>]

On Wed, Dec 05, 2007 at 04:24:02PM -0700, Alex Williamson wrote:
> Hi Simon,
> 
>    Sorry I haven't gotten a chance to test these extensively.  Thanks
> for your work debugging the failure on rx3600/rx6600; sounds like it was
> a fairly generic bug.  I did briefly test on my rx2620 that had the SAL
> errors before, they still occur :(  I'll try to debug this and maybe see
> if I can get it to reproduce on another system since that led to some
> useful hints with the previous issue.  I'm currently expecting that
> we'll get these into the tree after the 3.2 release, assuming we work
> out any remaining issues.  Thanks,

Yes, thats pretty much what I am thinking too.

What I'm working on right now:

   It seems that 16217:c17bfb09179095567c0cdae0aef3177afd6fad53
   "Make Xen relocatable" causes a regression that manifests
   on Tiger 2 by it getting stuck when booting the second
   hypervisor if the first hypervisor used more than one CPU.

   (XEN) register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level
   [ hang in SAL call not related to iosapic ]

   Once I had done the bisection to find the problem I thought
   that it would be a simple matter of unpinning the xenheap
   wherever the KERNEL_START (the hypervisor) is unpinned from the
   TLB. Baiscally in the rr7 updating routines, the tlb flushing
   routine (called by jump_to_sall) and relocate_kernel (which is
   provided by dom0). However, its proving a bit more tricky :(

Also, I noticed that I had been using rr incorrectly.
I was doing things like ia64_get_rr(7), when in
fact it should be ia64_get_rr(7 << 61). I acually doubt this
was causing any malfunctions, though it has interesting
security implications for HVM (i.e. security = no-security).
I'll fix this up and repost.

-- 
Horms


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