Re: [RFH] xen domain0 failover stuff

[Don Zickus <dzickus@redhat.com>]

On Mon, Mar 27, 2006 at 11:38:10PM +0100, Keir Fraser wrote:
> 
> On 27 Mar 2006, at 23:08, Don Zickus wrote:
> 
> >I am ignorantly trying to find a way to start a second domain0 when the
> >first domain0 crashes.  My original intent was to find a way to 
> >collect a
> >core file much in the same way the domainU core files are collected on 
> >a
> >linux box.
> >
> >I managed to hack in some hooks to get a second domain0 loaded and 
> >started
> >upon a crash.  However, I am stuck without console output, ie printk() 
> >is
> >not working.  Oddly, early_printk() works fine and I can sort of track 
> >the
> >progress of the second domain0 as it boots.  So my first question is 
> >how
> >does the serial console (not vga) magic work for a domain0 kernel?  Do 
> >I
> >have to set some internal domain bits to have the console output
> >redirected to the serial port as opposed to userspace and xend (ala
> >domainU kernels)?
> 
> The new domain0 must have SIF_INITDOMAIN flag set in its start_info 
> flags.
> 
>  -- Keir

Continuing on my project to get a domain0 to failover to a second domain0,
I have stumbled upon an out of memory problem.  Does anyone know what type
of quirky scenario I would have had to create in order to have
xen_create_contiguous_region() fail within
swiotlb_init_with_default_size() of the linux x86_64 kernel?  

I have managed to debug it down to alloc_heap_pages(MEMZONE_DMADOM, order)
returning NULL.  But my problem is I couldn't figure out how those heaps
were created in the first place.  

This domain is supposed to be configured with 256MB of memory (and "xm
list" confirms that).  So for the actual domain to run out of memory seems
illogical.  

Any thoughts, pointers, or help would be great.

Cheers,
Don