On Thu, 2013-02-14 at 12:53 +0000, Ian Campbell wrote:
I had observed once upon a time that turning up the limit caused odd failures, but I'd never associated it with the size. I spent ages trying to track down a NULL pointer in some level>3 message and the like...
In hvmloader I see: #define SEABIOS_PHYSICAL_ADDRESS 0x000E0000 which would have to change if the image grew >128K. Really hvmloader should check the size dynamically and DTRT. I can't remember why I did it this way.
No idea. If I just set .bios_address = 0x100000U - sizeof(seabios), it works just fine.
Sorry about this, crapness on our end I think :-(
Ahem, you also have //BUILD_BUG_ON(sizeof(seabios) > (0x00100000U - SEABIOS_PHYSICAL_ADDRESS));
Now *that* would have been a time-saver...
Another observation: 'xl -c seabios.cfg' misses the first output of the domain. Starting it *paused*, then running 'xl unpause seabios' in another terminal, lets me catch even the first 'Start bios ...' message.
If it *had* been crashing early in SeaBIOS, I'd have been cursing you for that one too :)
Anyway, I appear to have established that the qemu fw_cfg *doesn't* exist in your domains — so how you pass bootorder to the guest, if you successfully do so at all, I have no idea. And the patch at http://git.infradead.org/users/dwmw2/seabios.git/commitdiff/e62d1720f appears to work fine — at least in the case of a domain with nothing to actually boot from anyway, where we expect it just to die with 'no bootable device'.
I'll probably have a look at OVMF under Xen now, and making sure that my CSM code works there. Then you shouldn't need to offer people the choice between OVMF and SeaBIOS because you'll have one image that handles everything (which is what people get on real hardware, and expect).