From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42943 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q7tyu-0004vn-A5 for qemu-devel@nongnu.org; Thu, 07 Apr 2011 14:31:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q7tyt-0007UI-7F for qemu-devel@nongnu.org; Thu, 07 Apr 2011 14:31:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q7tys-0007U0-VF for qemu-devel@nongnu.org; Thu, 07 Apr 2011 14:30:59 -0400 Date: Thu, 7 Apr 2011 21:30:52 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] How does the QEMU load the binary files bios.bin and vgabios-cirrus.bin? Message-ID: <20110407183052.GC7100@redhat.com> References: <4D9DBC05.8010400@codemonkey.ws> <20110407153106.GA7100@redhat.com> <4D9DDB80.8090905@codemonkey.ws> <20110407155142.GB7100@redhat.com> <4D9DE166.9080001@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: Bei Guan , QEMU Developers On Thu, Apr 07, 2011 at 11:18:54AM -0700, Jordan Justen wrote: > On Thu, Apr 7, 2011 at 09:08, Anthony Liguori wro= te: > > On 04/07/2011 10:51 AM, Gleb Natapov wrote: > >> 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() > >> > >> =9A =9A cpu_x86_load_seg_cache(env, R_CS, 0xf000, 0xffff0000, 0xffff, > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9ADESC_P_MASK | D= ESC_S_MASK | DESC_CS_MASK | > >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9ADESC_R_MASK | D= ESC_A_MASK); > >> > >> =9A =9A env->eip =3D 0xfff0; > >> > >> Don't know how a20 gate is handled btw. > > > > I see that we use 0xf0000 in the kernel but this is because of a limita= tion > > of VMX. >=20 > I recently noticed that kvm does this. It does not seem to be a big > deal as firmware can easily deal with it, but I did find it odd that > kvm had the csbase of 0xf0000 as processors generally use a csbase of > 0xffff0000 initially. (At least, this is what I've seen with Intel > processors for the past 12 years.) >=20 > How can this limitation exist with VMX if mode transitions are > supported, in which case this type of csbase vs. real-mode segment > mismatch can easily occur? >=20 VMX does not support real mode, so KVM uses vm86 to emulate real mode. Vm86 does not support case when CS !=3D CS.BASE >> 4, so KVM needs to fall back to emulation if it occur. During mode transitions such situation usually exist for only a couple of instructions. This is one of the reasons why KVM does not support SMM. Newest Intel CPUs support real mode in VMX BTW. It is called "unrestricted guest" IIRC. > > I guess when 32-bit was introduced, this behavior was added. > > > >>> The CS base starts out at 0xf0000 and IP is 0xfff0. =9AThat gives a > >>> real address of 0xffff0. =9AThis 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). > > > > Indeed. >=20 > Another place this will often be seen is SMM, as the SMBASE can easily > be > 1MB, but the SMM entry is in 16 bit mode. >=20 > -Jordan -- Gleb.