Re: Dom0 PAE panic when starting xend

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Christoph Egger wrote:
> On Tuesday 03 March 2009 22:45:33 Jean-Yves Migeon wrote:
>> Manuel Bouyer wrote:
>>> I guess it's a side effect of the malloc implementation; but I don't
>>> think we can rely on it either. Better use uvm_km_alloc() for this; 
which
>>> take an explicit alignement parameter.
>> Well, the man page of malloc(9) does state that the return value is
>> suitably aligned. I thought the same about kmem_alloc(), but looks like
>> my supposition is wrong.
>[snip]
> I just tested your fix and xenstored still fails as before:
>
> (XEN) mm.c:712:d0 Error getting mfn 55555 (pfn 55555555) from L1 entry
> 0000000055555067 for dom0
> xpq_flush_queue: 1 entries
> 0x0000000102122608: 0x0000000055555067
> panic: HYPERVISOR_mmu_update failed

This fix was only meant to fix save/restore. I am currently looking at 
arch/xen for this one, it may or may not be related to the malloc => 
kmem_alloc thing.

> hmm... does the Dom0 use p2m at all ?

Nope.

My mail was not very clear. I just replied to explain the situation 
regarding the save/restore issue. In fact, the error was not in the p2m 
table (which is correctly handled by NetBSD), but in the autoconf code 
called upon first domU boot. The code worked before, but kmem_alloc() 
did return addresses aligned on a page boundary. For some reason, about 
a month ago, it did not any more (bad assumption on my part).

Sometimes, Xen expects addresses to be aligned on a page boundary, but 
the hypercall API does not make it very clear. Trouble is, the bug is 
not necessarily in the code calling the mmu_update routine.

That's why I am looking at the parts where malloc/MALLOC were replaced 
by some other allocation routines, just to see if that does not 
introduce a wacky issue that may come up later.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost