On 03.11.2009, at 05:50, Kevin O'Connor wrote:
On Mon, Nov 02, 2009 at 03:56:08PM +0200, Avi Kivity wrote:
On 11/02/2009 03:51 PM, Kevin O'Connor wrote:
On Mon, Nov 02, 2009 at 03:32:54PM +0200, Avi Kivity wrote:
Is seabios clobbering memory? Gleb/Kevin?
I have not tested with the -kernel option before. I believe you may
be running into the clearing of memory that PMM does - see
malloc_finalize() in src/pmm.c. The PMM spec requires that low
memory
be cleared before starting the boot process.
Likely. Alex, does -kernel use memory below 1MB? Can it be moved
elsewhere?
I've confirmed that commenting out the memset in malloc_finalize()
fixes the reported problem.
Removing the memset is probably okay for the short-term, but it would
contradict the PMM spec, so we'll need some kind of long-term
solution.
Also, SeaBIOS wont clear high-memory, but nothing stops SeaBIOS from
using high memory for scratch space during init.
If not, we probably need a protocol where the option rom loads the
kernel from qemu, rather than qemu poking the kernel into memory.
Yes, I'd prefer to see this. In earlier emails, Gleb made a reference
to a qemu-cfg "stream" interface that is used for acpi tables - maybe
the kernel could be put in one of the streams and the rom could copy
it into ram on boot.
I don't think streaming is the right approach here. Streaming would
mean the rom had to copy, which again either a lot of PIO accesses
(slow!) or a complicated DMA interface.
I'd rather go for a RAM poking approach. As soon as the option rom is
loaded, it calls qemu via PIO telling it to "load the kernel in RAM
now" and as of the next instruction everything's in place at the
determined addresses. It's not like we could do anything about the
physical layout in the option rom anyways, usually the kernel tells us
what that looks like.
Alex
Let me know what you wish to do.
-Kevin
