Re: [Xen-devel] Debugging Xen early boot

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, May 06, 2016 at 01:41:38PM +0000, Zytaruk, Kelly wrote:
> 
> 
> > -----Original Message-----
> > From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Jan
> > Beulich
> > Sent: Friday, May 06, 2016 8:54 AM
> > To: Zytaruk, Kelly
> > Cc: xen-devel@xxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] Debugging Xen early boot
> > 
> > >>> On 06.05.16 at 14:31, <Kelly.Zytaruk@xxxxxxx> wrote:
> > > As for the other question I am still curious as to how to debug early Xen.
> > > How was __start_xen written and tested, what sort of tools were used
> > > to debug it and get it working right?
> > 
> > I don't know how it was done here, but having been through the exercise of
> > debugging early boot code in other environments, I can only say: Get 
> > creative.
> > E.g. leverage whatever storage you have that persists across at least a warm
> > reboot. Depending on system I have found e.g. video RAM or some of the I/O
> > ports in the 0x80-0x8f range usable. I also recall that on one specific box 
> > I had to
> > resort to using some of the CMOS non-volatile RAM or even the RTC registers
> > that don't change rapidly.
> 
> Ouch! Sounds painful.  Looks like I had better hope that everything works 
> fine up until the end of the init of the 16550s :(

The way I troubleshooted some of the ns16650 issues when working on the
PCIe support was to use the VGA buffer and print characters there.

Had to hack the Xen to allow that and it was mostly just printing 'A'
->'Z' to figure out where my code broke.

Other options (now that I think of this) would have been to pass in
the PCIe device to a guest and run Xen within the guest. That is nested
virtualization with Xen and the card in it. But of course if you are
doing early bringup that won't help much.

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