|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX
> -----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
|
|
|
|
|