On Thu, Apr 07, 2011 at 11:18:54AM -0700, Jordan Justen wrote:
> On Thu, Apr 7, 2011 at 09:08, Anthony Liguori <anth...@codemonkey.ws> wrote:
> > 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()
> >>
> >> 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.
> >
> > I see that we use 0xf0000 in the kernel but this is because of a limitation
> > of VMX.
>
> 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.)
>
> 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?
>
VMX does not support real mode, so KVM uses vm86 to emulate real mode.
Vm86 does not support case when CS != 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. 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).
> >
> > Indeed.
>
> 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.
>
> -Jordan
--
Gleb.
