All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Bei Guan <gbtju85@gmail.com>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin?
Date: Thu, 7 Apr 2011 18:51:42 +0300	[thread overview]
Message-ID: <20110407155142.GB7100@redhat.com> (raw)
In-Reply-To: <4D9DDB80.8090905@codemonkey.ws>

On Thu, Apr 07, 2011 at 10:42:56AM -0500, Anthony Liguori wrote:
> On 04/07/2011 10:31 AM, Gleb Natapov wrote:
> >On Thu, Apr 07, 2011 at 08:28:37AM -0500, Anthony Liguori wrote:
> >>On 04/07/2011 03:22 AM, Bei Guan wrote:
> >>>Hi,
> >>>
> >>>I have some questions about the qemu's bios. How does the QEMU
> >>>load the binary files bios.bin and vgabios-cirrus.bin? Which
> >>>function or code file need I to pay more attention to?
> >>>
> >>>For the loading of vgabios-cirrus.bin and bios.bin, I just trace
> >>>them into the same funciton rom_add_file() in hw/loader.c. Is it
> >>>the right function, which loads the bioses?
> >>>
> >>>And then another question, how qemu give the control to bios when
> >>>the bios file is loaded? Maybe this question is not in the scope
> >>>of qemu, however, can you give me some cue point.
> >>I had some stuff written up locally so I posted it to the wiki at
> >>http://wiki.qemu.org/Documentation/Platforms/PC
> >>
> >>The x86 architecture defines the initial state of the chip to have
> >>the CS register have a base of 0xF000 and an IP of 0xFFF0.  The
> >>result is that the actual memory address of the first instruction
> >>falls at the end of the BIOS ROM segment.  This is the entry point
> >>to the BIOS.
> >>
> >Actually after reset on x86 IP=0x0000fff0, CS=0xf000, CS.BASE= 0xffff0000,
> >CS.LIMIT=0xffff. So the execution begins at 0xfffffff0 where ROM is
> >mapped initially.
> 
> That impossible because 1) the processor starts in 16 bit mode so
> such an address cannot be generated 2) the processor has a20 held to
> zero which makes that the processor cannot generate a load to an
> address with the 20th bit set to anything but zero.
> 
That may seams to be impossible but it is how HW works. And this is how
QEMU emulates it. Look at target-i386/helper.c:cpu_reset()

    cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff,
                           DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
                           DESC_R_MASK | DESC_A_MASK);

    env->eip = 0xfff0;

Don't know how a20 gate is handled btw.

> The CS base starts out at 0xf0000 and IP is 0xfff0.  That gives a
> real address of 0xffff0.  This is usually a trampoline to somewhere
> else in the space.
CS descriptor and CS selector don't have to be in sync (big real mode).

> 
> The mapping of BIOS to the top of 4GB is just a convention that
> modern BIOSes use because the legacy space isn't big enough for most
> modern BIOSes.
> 
> Regards,
> 
> Anthony Liguori
> 
> >>The VGABIOS is treated like any other option ROM and is initialized
> >>during option ROM scanning.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >>>Any reply are appreciated. Thanks.
> >>>
> >>>Gavin
> >>>
> >>>
> >>>
> >>>
> >--
> >			Gleb.
> >

--
			Gleb.

  reply	other threads:[~2011-04-07 15:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-07  8:22 [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin? Bei Guan
2011-04-07 13:28 ` Anthony Liguori
2011-04-07 15:31   ` Gleb Natapov
2011-04-07 15:42     ` Anthony Liguori
2011-04-07 15:51       ` Gleb Natapov [this message]
2011-04-07 16:08         ` Anthony Liguori
2011-04-07 18:18           ` Jordan Justen
2011-04-07 18:30             ` Gleb Natapov
2011-04-07 18:37             ` Anthony Liguori
2011-04-07 18:37               ` Anthony Liguori
2011-04-07 18:44               ` Gleb Natapov
2011-04-07 18:44                 ` Gleb Natapov
2011-04-07 19:03                 ` Jordan Justen
2011-04-07 19:03                   ` Jordan Justen
2011-04-07 19:16                   ` Gleb Natapov
2011-04-07 19:16                     ` Gleb Natapov
2011-04-07 19:24                   ` Olivier Galibert
2011-04-07 19:24                     ` Olivier Galibert
2011-04-07 19:58                     ` Jordan Justen
2011-04-07 19:58                       ` Jordan Justen
2011-04-07 19:21                 ` Anthony Liguori
2011-04-07 19:31                   ` Gleb Natapov
2011-04-07 21:34                     ` Anthony Liguori
2011-04-08  5:58                       ` Gleb Natapov
2011-04-07 19:47                   ` Jordan Justen
2011-04-07 19:47                     ` Jordan Justen
2011-04-07 17:30       ` malc
2011-04-07 17:07   ` Bei Guan
2011-04-07 17:31     ` Bei Guan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110407155142.GB7100@redhat.com \
    --to=gleb@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=gbtju85@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.