On 10.11.2009, at 14:02, Avi Kivity wrote:
On 11/09/2009 08:41 PM, Glauber Costa wrote:
pc.c:
} else {
/* High and recent kernel */
real_addr = 0x10000;
cmdline_addr = 0x20000;
prot_addr = 0x100000;
}
If I'm not totally mistaken, 0x10000 is< 1MB :-).
So yes, I think there should be a fw-conf interface that tells
qemu to
reload all volatile option rom regions (which it keeps track of for
reset anyway). We just need to make sure it doesn't overwrite the
BIOS
itself, as data in there might have been changed already.
Can't we put these data somewhere else, and let our int19 handler
copy
it to the right location?
Anywhere you put it the bios has a right to trample. Of course our
bios (and its maintainer) are cooperative, but there's not reason to
impose on that if we can do the right thing and load the data at the
right moment.
Right. The only thing we're missing is soft breakpoints set in gdb
when running the guest with -s -S, as the guest kernel just isn't
there by then yet.
But I guess we can live without that feature, as long as the rest works.
Alex