This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] fix for Failed VMEntry on VMX
From: "Dave Lively" <dave.lively@xxxxxxxxx>
Date: Tue, 2 May 2006 12:04:36 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 02 May 2006 09:05:01 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dJCYhreWF58chDJiXS/cIRzTJyelDm4NUngCJuAHW+HHmG802Qkc+oNSBMe7bcl9CtDR/4PFBmkdODH4FcxFBWyVLn/jUOx3hUueUw172f3WCNeMADUtVuXhXA+vKhkKZeZqaGTog1QZxudNVS35tv5c+cX2/ObqUcJACpCLz+o=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0BA7FC18@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <907625E08839C4409CE5768403633E0BA7FC18@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I don't think so.  If a CPU in real mode is allowed to use
a segment base set in another mode (to something other than
sel << 4), I think that's outside the scope of what vmxassist
was designed to do.  (Because vmxassist relies on vm86 mode,
and the VMX spec says vm86 mode guests must have their segment
bases = sel << 4 upon vmentry ... and the chips certainly behave
as specified in this regard.)

I don't really understand the implications of not supporting arbitrary
segment bases in real mode guests (what code actually does this?),
but since it can't work in the current implementation, this patch must
not be breaking it ...

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...


Xen-devel mailing list