Re: Dom0 PAE panic when starting xend

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

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.
>
> >> Who is at fault here? Should NetBSD add some checks against invalid
> >> mappings (when hypercall returns EINVAL for a foreign domain), or should
> >> xentools check the validity (against a poison for example) and abort the
> >> operation if it triggers?
> >
> > If the hypercall returns a proper error code, it should be used and
> > handled appropriately, I'd say.
>
> In fact, we end up like this:
>
> - first, we try the mapping inside the IOCTL_PRIVCMD_MMAP(BATCH); when
> it fails (pmap_enter_ma returns an error), we flag the address as
> invalid inside the privcmd_object/uobj.
>
> - second, when privpgop_fault is called. However, we never fall back to
> pmap_enter_ma (which will return the same error as before): we check
> against INVALID_PAGE, and if positive, issue a continue. Since error is
> set to 0 by default, we end up in a loop with privpgop_fault.
>
> IMHO, in case of an INVALID_PAGE, we should return EFAULT, just to
> indicate that the thing is indeed wrong, like in [1]. The caller is free
> to find through the ioctl which element in the array is faulty.
>
> [1] http://www.netbsd.org/~jym/privcmd.diff

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

fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c02125f4 cs 9 eflags 246 cr2 bb6c1800 ilevel 6
Stopped in pid 369.1 (xenstored) at     netbsd:breakpoint+0x4:  popl    %ebp
db> bt
breakpoint(c0998c36,cdbbc988,c09b7500,c05fd66b,c099f8ed,5,0,0,cdbbc998,ffffffea)
 at netbsd:breakpoint+0x4
panic(c099f903,2122608,1,55555067,0,cdbbc9ac,0,c0761ac6,cabfd484,c0a9129c) at 
netbsd:panic+0x1a4
xpq_update_foreign(2122608,1,55555067,0,cdb6bce0,0,cdbbca1c,c05f636c,cdb48910,cd
b6bce0) at netbsd:xpq_update_foreign
pmap_enter_ma(cda80c98,bb6c1000,55555000,0,55555000,0,3,23,7ff0,3) at 
netbsd:pmap_enter_ma+0x580
pmap_enter(cda80c98,bb6c1000,55555000,0,3,23,cdf74490,0,c16fa680,bb6c1000) at 
netbsd:pmap_enter+0xd3
udv_fault(cdbbcc70,bb6c1000,cdbbcc30,1,0,1,5,c044b616,cdb6bce0,cda935ec) at 
netbsd:udv_fault+0x491
uvm_fault_internal(ca89fa90,bb6c1000,1,0,cdf3a65c,0,0,cda935e0,0,c09f74b0) at 
netbsd:uvm_fault_internal+0x8e5
trap() at netbsd:trap+0x6e0
--- trap (number 6) ---
0x804e512:
db> x l3_p2m_page
netbsd:l3_p2m_page:     0
db> x l2_p2m_page
netbsd:l2_p2m_page:     0
db> x l2_p2m_page_size
netbsd:l2_p2m_page_size:        0
db>

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

Christoph