On Mon, Nov 02, 2009 at 03:06:45PM +0100, Alexander Graf wrote:
> 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.
Can't we put these data somewhere else, and let our int19 handler copy
it to the right location?
