> That would be terrifying. Presumably there's a jmp past that
> ret somewhere. I got the impression from your first email
> that some guests do boot, and that can only happen through that iret.
I put an int 3 as the first instruction in the ASM block, but didn't hit
it. But maybe int3 handler just does a return.
I double checked and 32bit guest on 32bit hv works, but the test was
performed with a build from a system with bcc 0.16.17, which is not the
version that we are seeing failures from. So, currently failures only
occur with the older bcc version.
> Yep. What version of bcc are you using? (bcc -v says 0.16.14 for me)
Well, I am using SLES9.3 installed base, and bcc -v, says "no input
file", a man of bcc doesn't show any way to get the version :P, hmmm.
Here is file, and ls -l info:
/usr/bin/bcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
-rwxr-xr-x 1 root root 16304 Mar 19 2005 /usr/bin/bcc
I'll find a more recent system to build on with newer bcc. Our build
server xen is also based on SLES9.3 with same bcc, and failure occurs
from xen builds generated from these also.
> Does adding an explicit "return;" in C after the asm block
> change the behaviour?
No. didn't help, code is the same in generated rombios.s. I put in a
"call" instead and move the ASM boot code up, but same behavior/code
generation. Looks like there has to be some "C" code after the switch
or the asm code doesn't get called.
> ...and can you send me a full copy of rombios.s from the build?
Attached are 2 rombios.s files in tar.bz2, appended the changeset to the
filename. Let me know if you don't get these, our firewall has been
doing some strange things lately.
Sure does look like the code generated isn't correct with older bcc..
But a few more tests will confirm or deny.
Thanks for looking at this!
Xen-devel mailing list