Re: [Xen-devel] SeaBIOS build issue

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

Il 23/08/2013 10:18, Ian Campbell ha scritto:
> 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.
Has Someone done/doing this patch for seabios?
Thanks for any reply.

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

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