Re: [Xen-ia64-devel] EFI Mapping Windows Install Crash Bug

[Simon Horman <horms@xxxxxxxxxxxx>]

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