Re: [Xen-devel] Fwd: NetBSD xl core-dump not working... Memory fault (core dumped)

[James Harper <james.harper@xxxxxxxxxxxxxxxx>]

> 
> On 10/12/13 08:21, James Harper wrote:
> > I've been working with Mike on this today. After he re-applied the patch
> (something must have gone wrong initially), an ioctl error is repeated
> constantly instead of SIGSEGV:
> >
> > xc: error: xc_map_foreign_range: ioctl failed (14 = Bad address): Internal
> error
> >
> > I dumped out some of the variables though, and:
> >
> > nr_memory_map = 1
> > pfn_start = 0, pfn_end = 1048575
> >
> > this equates to 4GB of pfn's to be dumped on a vm with mem/maxmem =
> > 256MB... is there code that skips empty pages? If not, that seems to be the
> > explanation for the errors.
> >
> > James
> 
> xc_map_foreign_range is completely broken as far as errors go.
> 
> The privcmd driver ends up doing:
> 
> if ( HYPERVISOR_mmu_update(foo,bar) < 0 )
>     return -EFAULT;
> 
> Your best bet here is intercepting this and finding the real error.
> 
> privcmd (and evenchn and gnttab) devices are generally broken as far as
> errors go, because it is impossible to distinguish between a kernel
> error and a Xen error.
> 
> 
> In someones copious free time, (possibly mine if I ever get any) a brand
> new set of ioctls on each of the Xen devices would not go amis.
> 

I think that the core dump stuff just iterates over the whole memory range and 
skips anything that xc_map_foreign_range returns an error on. After applying 
the patch that caused the resulting vaddr to sigsegv, the only problem was that 
it logged an error when trying to map a page. Rmoving that perror is appears to 
be sufficient for now, although maybe it should only do it on certain errors...

James

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel