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 Tue, Jul 01, 2008 at 09:20:27PM +1000, Simon Horman wrote:
> On Tue, Jul 01, 2008 at 08:04:16PM +0900, Isaku Yamahata wrote:
> > On Tue, Jul 01, 2008 at 05:34:42PM +1000, Simon Horman wrote:
> > > On Tue, Jul 01, 2008 at 04:07:53PM +0900, Isaku Yamahata wrote:
> > > > On Tue, Jul 01, 2008 at 11:03:28AM +1000, Simon Horman wrote:
> > > > > Hi,
> > > > > 
> > > > > I'm a bit hesitant to jump the gun, but I think that I might have
> > > > > isolated the cause of win2k3-sp2 crashing during install when my EFI
> > > > > Mapping patches are applied. Well, perhaps not the cause, but I think 
> > > > > I
> > > > > know where it is dying.
> > > > > 
> > > > >     Quickly as background, the EFI Mapping parches move the mapping
> > > > >     that EFI is taught on boot time to map memory where Linux places
> > > > >     it ( basically pa + (0xe<60) ) instead of where Xen usually
> > > > >     places it ( basically pa + (0xf<60) ). In order to protect this
> > > > >     mapping from HVM domains a special region id is used. The
> > > > >     hypervisor switches to that region id just before making any
> > > > >     PAL, SAL or EFI calls, and switches back to the previous region
> > > > >     id once the call completes.  As region 7 has to be changed,
> > > > >     entries that are pinned into the TLB have to be repinned. And
> > > > >     that is roughly where the fun begins.
> > > > > 
> > > > > As for the problem? It seems to be caused by ia64_mca_cpe_int_caller()
> > > > > calling ia64_log_queue() which calls ia64_sal_get_state_info(). I
> > > > > believe that the hypervisor dies in ia64_log_queue() somewhere after
> > > > > ia64_sal_get_state_info() completes. That is, I am suspecting that the
> > > > > call to ia64_sal_get_state_info() is returning bogus data.
> > > > 
> > > > Is ia64_mca_cpe_int_caller() called in interrupt context?
> > > > If so, ia64_log_queue() calls xmalloc() which can't be called
> > > > from interrupt context. Then xen VMM crashes at ASSERT(!in_irq())
> > > > in _xmalloc().
> > > 
> > > That is a good point. Although xmalloc() is only called if
> > > ia64_sal_get_state_info() returns a non-zero value. Which
> > > according to tracing that I have done this afternoon, does
> > > not seem to be the case (when ia64_log_queue() is called
> > > from other places in mca.c.
> > > 
> > > How can I check if the call is being made in interrupt context?
> > 
> > in_irq()?
> > Anyway I noticed ia64_mca_cpe_int_caller() is a irq handler so that it is 
> > always called from intrrupt context. So ia64_log_queue() has to be
> > fixed in case ia64_sal_get_state_info() returns > 0.
> 
> I'm actually not sure that code path ever gets exercised,
> because as you say, if it did then the ASSERT(!in_irq()) in
> _xmalloc() wound be triggered.
> 
> This seems to imply that ia64_sal_get_state_info() always returns 0
> if called from an interrupt context - my debuging backs this up.

I supopse fault injection or something like that might be needed to
test the execution path.

> 
> 
> As for the EFI RID related problem that I am seeing. I am getting some
> good results by translating the log_buffer argument to
> ia64_sal_get_state_info() to an EFI virtual address (basically 0xe...
> instead of 0xf...). I am sure that I tried this before and it failed.
> But this time it seems to be working, so perhaps it is a combination of
> this change and other changes.

As I'm reviewing the patches, I noticed only xen/arch/ia64/xen/ivt.S
is patched, but xen/arch/ia64/xen/vmx_ivt.S isn't patched.
Isn't it necessary to similar change to vmx_ivt.S?


-- 
yamahata

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