qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE


From: Glauber Costa
Subject: Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE
Date: Mon, 9 Nov 2009 16:41:57 -0200
User-agent: Jack Bauer

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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]