RE: [Xen-devel] [Patch] Fix for x86_64 boot failures due to badsegment setup for protected mode.

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

This patch caused one problem.

If the guest change the DS/SS etc between it set cr0.PE and the jump 
instruction.
Considering following code:
   mov eax, cr0
   or eax, 0x11
  mov cr0, eax          ---> here enable PE, and old_ctx.ds is cleard
   mov ax, 0x0020
   mov ds, ax           -> changes the DS here
  jmp pword ptr [edi + 0x60]
  mov ax, word ptr [bx + 0x00a8]

The vmxassit clear the oldctx.ds_sel when guest enable PE, and when guest 
executed the mov ds, ax, the content on oldctx is not updated. Later when the 
last instruction, the ds is infact 0x0, not the 0x20 as guest hoped.

This issue is in fact not caused entirely by this change, since we should 
emulate all instructions between the set cr0.PE and the jump instruction. But 
because the "mov ds, ax" is in fact executed by guest, not by vmxassist, it do 
cause problem for us.

Thanks
Yunhong Jiang

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Stephen C. Tweedie
Sent: 2006年11月10日 1:31
To: Keir Fraser
Cc: Yu, Wilfred; Xin, Xiaohui; xen-devel@xxxxxxxxxxxxxxxxxxx; Herbert Xu; Li, 
Susie; Steven Rostedt; Li, Xin B
Subject: Re: [Xen-devel] [Patch] Fix for x86_64 boot failures due to badsegment 
setup for protected mode.

Hi,

On Thu, 2006-11-09 at 14:08 +0000, Keir Fraser wrote:

> A smaller patch might have been to implement those VMENTER sanity checks
> inside load_seg(). I'm sure they're quite simple. 

I checked, as that was going to be my first approach.  Turns out that
they are not actually all that simple, with all sorts of different rules
for base, size, access rights, type, flags and so on, dependent on which
segment it is, whether it's 16 or 32-bit, etc.  

They aren't _too_ tricky, but after looking at it some, there are enough
rules there that I was actually more worried about introducing a
regression going down that route than in the patch I ended up with.

Cheers,
 Stephen



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

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