RE: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> David Lively
> Sent: 02 May 2006 15:58
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX
> 
> I've been getting a "Failed VMEntry" when trying to boot a 
> second VMX guest (while the first one is still running, but 
> is no longer in real mode).  This patch fixes it.
> 
> VMX(assist) uses vm86 in its real mode emulation.  Upon 
> vmentry into a guest in vm86 mode, all segment bases must be 
> equal to the corresponding segment selector shifted left four 
> bits.  The vmx routine vmx_load_cpu_guest_regs() was loading 
> the segment selectors.  Now it makes sure to set the segment 
> bases appropriately if we're in vm86 mode.
> 
> Tested on 64bit hypervisor with 2 64-bit VMX domUs (on 2-way dom0).

Will this not break "big real-mode" type behaviour? Or am I missing
something here? Certainly the x86 architecture itself allows the segment
(in real mode) to have a different base address than the "selector << 4"
that you get when you LOAD a selector in REAL MODE. It's just that in
real-mode, you can't set a different base, but code that has temporarily
run in non-real mode (i.e. enter protected mode then set segment
register than exit back to real-mode) can do all sorts of magic. If this
is really expected behaviour, it would also be expected to have a limit
of 0xffff, or you're sort of half-breaking the rules still... 

--
Mats
> 
> Dave
> 


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