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:
>>
>>> On 11/02/2009 03:15 PM, Alexander Graf wrote:
>>>
>>>> They are taken with -d in_asm,cpu,int after doing:
>>>>
>>>> $ ./x86_64-softmmu/qemu-system-x86_64 -kernel
>>>> ../kvm/arch/x86/boot/bzImage
>>>>
>>>> with a fresh checkout from your kvm kernel tree (make defconfig) and a
>>>> fresh git checkout of qemu (./configure --target-list=x86_64-softmmu)
>>>>
>>>>
>>>> They basically mean that with SeaBIOS the Linux loading code is trying
>>>> to jump off to zeros while at the same place there is useful data
>>>> using
>>>> pcbios.bin.
>>>>
>>>>
>>> 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?
>
> If not, we probably need a protocol where the option rom loads the
> kernel from qemu, rather than qemu poking the kernel into memory.
>
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.
Alex
