Re: [Xen-devel] SeaBIOS build issue

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-08-22 at 17:01 +0100, Jan Beulich wrote:
> Ian,
> 
> so sadly this is another of those cases where I spent several hours
> finding a rather trivial build problem: On an older system of mine,
> the SeaBIOS image ends up being 256k in size instead of the
> expected 128k (the actually used size is about 133k, apparently
> getting rounded to the next power of two). The attempt to load
> that image therefore results in hvmloader's text to be overwritten,
> causing the VM to crash silently (i.e. one first needs to go and add
> debugging code to find where the crash really happens).
> 
> Upon checking I can see that the same happens on a second system.
> I didn't notice this so far because on those systems, being old, I
> rarely run HVM guests.
> 
> Interestingly enough there's a commented out BUILD_BUG_ON() in
> hvmloader/seabios.c. Why's that commented out?

I'm sorry but I really don't remember.

Trivially uncommenting it fails, because BUILD_BUG_ON must be used in
function scope (maybe I had a brainfart and forgot this when I wrote the
code which lead to me commenting it out). Moving it into a function (I
arbitrarily chose seabios_setup_bios_info) works for me -- does it
correctly fail for you?

>  and if it already
> is commented out, rather than crashing the VM very early, wouldn't
> it be possible for hvmloader to at least print an error message and
> exit?

Yes, that would be an excellent improvement.

> And then to the build problem itself - the way that they put
> together the binary image (via computing linker scripts listing the
> sections in machine-adjusted order) makes it close to impossible to
> find out where things go wrong. I decided to stop my attempts to
> understand that logic after having wasted 2+ hours on this. I have
> a vague feeling that less (or no) inlining may be representing part
> of the problem.

This is an area of SeaBIOS which I don't really understand myself. I do
know that it is very sensitive to compiler and binutils versions because
of some of the magic it does, especially with older ones. IME it
generally tests for those issues and aborts the build rather than
building something bad -- but I guess being 256k isn't actually bad in
isolation.

I've found the seabios@xxxxxxxxxxx list and Kevin in particular to be
very helpful in answering these sorts of questions.

> So the question now is - can one somehow, without too much
> trouble, trick the hvmloader build into using a pre-generated (e.g.
> on another system, where a known good binary results) SeaBIOS
> binary, without subsequent rebuilds trying to overwrite that one?
> Or can you see any other solution to that problem, not involving
> doing the whole build on a different machine?

I think in tools/firmware/hvmloader/Makefile you can just override
SEABIOS_ROM.

If you wanted to avoid pointlessly building tools/firmware/seabios-dir
at the same time, I think you just need to comment out the relevant
SUBDIRS line in tools/firmware/Makefile.

Ideally this would be integrated into a ./configure
--with-system-seabios=PATH option, in a similar manner to 5c7cbadaccca
"tools: allow user to specify a system qemu-xen binary".

Ian.


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