[SeaBIOS] Problem with Debug lvl under XEN

Ian Campbell Ian.Campbell at citrix.com
Tue Feb 14 11:08:04 CET 2012

On Tue, 2012-02-14 at 00:33 +0000, Kevin O'Connor wrote:
> On Mon, Feb 13, 2012 at 08:50:56PM +0000, Ian Campbell wrote:
> > On Mon, 2012-02-13 at 23:21 +0900, Daniel Castro wrote:
> > > Hello,
> > > 
> > > I have encountered something a little strange, if I set up the debug
> > > lvl to 3 or more Y will get a Triple VCPU fault. If I set it to 1 the
> > > bios runs normally but I loose a lot of information that I need to
> > > debug. Sometimes if I try to print char * variables regardless of the
> > > debug level I still get the fault.
> > > 
> > > Any ideas why?
> > 
> > My guess is that there is a debug print at lvl>=3 which ends up
> > dereferencing a NULL pointer in one of its arguments (probably a %s) and
> > this leads to a page fault. This in turn leads to a double fault because
> > SeaBIOS does not install a page fault handler and then a triple fault
> > because it also does not install a double fault handler. Likewise when
> > you are printing "char * variables regardless of the debug level".
> SeaBIOS doesn't have paging enabled, so it should not need to install
> a page fault handler.

Doh, yes you are obviously right!

In my defence when running virtualised paging may actually be enabled
contrary to what the guest thinks is going on (I think this is needed in
order to run real-mode code on EPT with a 1-1 map).

Really the hypervisor should completely hide this from the guest. I'm
not actually sure what Xen does but it may well take the easy way out
and rely on the BIOS not faulting... It still ought to print at least
the faulting address and IP on triple fault though. It may be useful for
Daniel to patch xen/arch/x86/hvm/hvm.c:hvm_triple_fault to add this

>   SeaBIOS needs to write the real-mode interrupt
> descriptor table to address 0, so it should definitely have read/write
> access to the memory there.  Thus, a null pointer dereference
> shouldn't cause a fault.  Indeed, I can't think of much that should
> cause a fault (other than read/write to IO memory incorrectly, divide
> by zero, invalid opcode, etc.).

An invalid pointer other than NULL might also do it, e.g. I think Xen
scrubs memory (in a debug build) to something like 0xcc.

In that case a NULL check won't work but I suppose one could use a patch
which treats %s as %p for the purposes of debugging it...

> > You could test this by adding an explicit check for null in the bit of
> > bvprintf which handles %s, perhaps putc()ing "(null)" instead.
> If you think it is specific to the Xen handling, one could also try
> running the same code on qemu to verify it.

Also trying the underlying SeaBIOS version without any local patches
would be a good idea if you haven't already.


More information about the SeaBIOS mailing list