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] EFI Mapping Windows Install Crash Bug

On Thu, Jul 03, 2008 at 08:50:56PM +1000, Simon Horman wrote:
> 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.

That's great.
Table 9-2 SAL spec says that SAL_GET_STATE_INFO is NOT reentrant,
the above explains why the hypervisor locks up.

> 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

Yes, now the next question is why the mca occurs and
whether it can/should be avoided.

Is it possible to determine what mca occurs?
The mca record might be in nvram, if so there should be a way
to retrieve them.
-- 
yamahata

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