Re: [Xen-devel] [Patch] Fix for x86_64 boot failures due to bad segment setup for protected mode.

["Stephen C. Tweedie" <sct@xxxxxxxxxx>]

Hi,

On Thu, 2006-11-09 at 08:56 +0000, Keir Fraser wrote:
> On 9/11/06 3:49 am, "Stephen C. Tweedie" <sct@xxxxxxxxxx> wrote:
> 
> > The fix is to save the 16-bit segments *always*, on entry to protected
> > mode when %CR0(PE) is first set; and to clear the saved 16-bit segment
> > and set the 32-bit variant in oldctx whenever a 32-bit segment
> > descriptor is set during the transition to 32-bit CS.  Then, when we
> > finally do the VMENTER, we will set up the VMCS from only the 32-bit
> > segments, clearing the VMCS entries for segments that have not been
> > assigned valid 32-bit segments yet.
> 
> So, after setting CR0.PE but before doing a jump to complete the transition
> to protected mode, is the guest now running with zeroed data selectors but
> with the old 'shadow segment state'? 

I tried to change the code as little as possible to minimise
regressions, as I don't have the full battery of guest OSes to test.

But the intention at least was that the guest shouldn't change much as a
result of the patch.  We're still running entirely in vmxassist
VM86_REAL_TO_PROTECTED mode during the change; the actual vmcs does not
get changed until we go to VM86_PROTECTED mode (and not at all if we
return to real mode before getting that far.)

So the guest selectors as far as the CPU is concerned are still the
selectors we set up to run vmxassist; and the selectors in effect as far
as the emulated guest OS code is concerned remains the old 16-bit
segments that vmxassist uses during that emulation.

The numerical offset that the guest sees as a selector when reading
es/ds etc. should not change, as the patch doesn't touch regs at all.  

This actually highlights the fact that vmxassist's emulation for real-
to-protected mode is pretty minimal, and in fact it passes the buck to
VMENTER earlier than it should.  It does so as soon as CS goes 32-bit,
but the other registers are still 16 bit and there's no theoretical
reason why a guest couldn't try to access 16-bit data/stack segments
from a 32-bit CS.  I haven't touched any of that --- the logic is still
that when we drop to true 32-bit VMENTER, segments that were 16-bit are
cleared.  I just changed the logic to make sure that we are better at
detecting which segments still contain 16-bit descriptors, and which
ones have been reloaded from the GDT and hence should survive into 32-
bit mode.

The fact that each segment has multiple different interpretations here
--- in the vmxassist context itself, in the guest VMCS, and in the guest
visible register set, doesn't help the discussion so I may have
misunderstood your question or been unclear in my reply!

Cheers,
 Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel