Re: [Xen-devel] BUG at domain.c:144

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> > It's important to ensure you are using a debug build of Xen (debug=y 
> > make). 
> 
> I edited the Rules.mk file and changed verbose and debug to y.
> 
> > Also, the guest backtrace will not be in a particularly pretty 
> > format. You may just want to post it here but we will definitely also 
> > require a link to your vmlinux file (i.e., non-compressed Linux image 
> > that has not been stripped of symbol info). We can then match likely 
> > addresses in the backtrace to code points in the objdump'ed kernel 
> > image.
> 
> http://www.theshore.net/~caker/xen/BUGdomain/

Okay, this is progress. The domain is dying because it is trying to
map a page that does not belong to it -- in fact it is a reserved page
in the ACPI NVS (Non-Volatile Store) area.

Unfortunately we batch page mappings and they get validated some time
after the problem code was actually executed. :-(

To get a fault at the actual point the mapping is requested, you need
to change a line in linux/include/asm-xen/asm-i386/pgtable-2level.h. 
The line is:
#define set_pte(pteptr, pteval) (*(pteptr) = pteval)
and should be changed to:
#define set_pte(pteptr, pteval) \
    xen_l1_entry_update((pteptr), (pteval).pte_low)

If you build and retry, we should get a guest backtrace at the code
point that is making the invalid mapping.

I'm going to be away for the next week, but I will look at your new
trace when I get email access. Alternatively Ian or Christian may have
time to decipher the backtrace. :-)

 -- Keir

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