| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
Re: [Xen-ia64-devel] EFI Mapping Windows Install Crash Bug
Hi,
I have been looking over the SAL manual and looking into where
exactly the lockup that I am seeing occurs.
What seems to happen is this.
If ia64_mca_cpe_int_caller() is called from vmx context (is that the
right word?) then when it calls ia64_log_queue() which in turn calls
ia64_sal_get_state_info() then as the SAL_GET_STATE_INFO call is being
made (I'm pretty sure that it is inside the firmware)
ia64_mca_ucmc_handler() is invoked. I presume that this is because an
unrecoverable machine check occurs during the SAL_GET_STATE_INFO call.
The call to ia64_mca_ucmc_handler() seems to complete successfully
(including a call to ia64_sal_get_state_info() via ia64_log_queue()).
Just after that the hypervisor locks up, presumably because execution
goes back to the original SAL_GET_STATE_INFO call that caused the
unrecoverable machine check.
With regards to rr7. It is not set to EFI RR when entering
ia64_mca_cpe_int_caller(), but it is when entering
ia64_mca_ucmc_handler(), which makes sense, as it should be set when
going into the first SAL_GET_STATE_INFO call.
My latest micro-hack involves having ia64_sal_get_state_info() return 0,
without going into SAL, if VMX_DOMAIN(current) is true, which seems to
work.
I will ponder the SAL manual some more to try and work out why
EFI RR + VMX (+ IRQ?) + SAL_GET_STATE_INFO -> bad
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home