Re: Dom0 PAE panic when starting xend

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Mar 03, 2009 at 10:45:33PM +0100, 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.

AFAIK this means that it's aligned to the native size of the CPU, i.e.
4 or 8 bytes in most cases.

> 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

Yes, that may be the right thing to do.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--