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? 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? 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. 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? Jan
Fedora has a patch that allows custom location of seabios. On Thu, Aug 22, 2013 at 10:01 AM, Jan Beulich <JBeulich@suse.com> 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? 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? > > 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. > > 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? > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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@seabios.org 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.
>>> On 23.08.13 at 10:18, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Thu, 2013-08-22 at 17:01 +0100, Jan Beulich wrote: > >> 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.Correct. It is our glue code that's problematic (and once a few more additions to the BIOS gets done, more tool chains may end up running out of the pre-set 128k. Therefore I went and tried whether removing that limitation just in hvmloader's glue code would work, and voilà - it does. I'll send a patch once I settled on a final shape for this.> I've found the seabios@seabios.org list and Kevin in particular to be > very helpful in answering these sorts of questions.And I'll send a desirable in my opinion adjustment to the SeaBIOS build process there - rather than bumping anything beyond 128k to 256k, it seems slightly better to do the bumps in 64k increments (and perhaps one could use even smaller steps), thus leaving a hole of at least 64k even in the problem case here. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Fri, 2013-08-23 at 13:16 +0100, Jan Beulich wrote:> >>> On 23.08.13 at 10:18, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Thu, 2013-08-22 at 17:01 +0100, Jan Beulich wrote: > > > >> 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. > > Correct. It is our glue code that's problematic (and once a few more > additions to the BIOS gets done, more tool chains may end up > running out of the pre-set 128k.Right, it's pretty close on my system already (124k)> Therefore I went and tried whether removing that limitation just > in hvmloader's glue code would work, and voilà - it does. I'll send > a patch once I settled on a final shape for this.Great, thanks.> > I've found the seabios@seabios.org list and Kevin in particular to be > > very helpful in answering these sorts of questions. > > And I'll send a desirable in my opinion adjustment to the SeaBIOS > build process there - rather than bumping anything beyond 128k to > 256k, it seems slightly better to do the bumps in 64k increments > (and perhaps one could use even smaller steps), thus leaving a > hole of at least 64k even in the problem case here.Sounds good. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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@seabios.org 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@lists.xen.org > http://lists.xen.org/xen-devel
On Mon, 2013-08-26 at 15:18 +0200, Fabio Fantoni wrote:> Il 23/08/2013 10:18, Ian Campbell ha scritto:> > 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".> Has Someone done/doing this patch for seabios?Not as far as I know, it''s on my TODO but not near the top. Please feel free to send a patch. You should be able to use the --with-system-qemu option for guidance. Ian.