WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] x86-64: syscall/sysenter support for 32-bit apps

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86-64: syscall/sysenter support for 32-bit apps
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 05 Jul 2007 16:16:28 +0100
Delivery-date: Thu, 05 Jul 2007 08:13:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2B2BAC0.11E84%Keir.Fraser@xxxxxxxxxxxx>
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: <468D094C.76E4.0078.0@xxxxxxxxxx> <C2B2BAC0.11E84%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 05.07.07 16:12 >>>
>I changed my mind on the emulation of MSRs, since we change the semantics of
>syscall/sysenter quite significantly. I don't think it is a good idea to get
>into emulating real MSRs but with modified semantics. It'll send us mad.

But that is in my opinion the only way allowing the guest OS code to
get away without significant Xen-special code (most of what is there
is now CONFIG_XEN_COMPAT-framed, i.e. should be possible to drop
at least when targeting mainline Linux).

>The comments in the public header are pretty confusing, especially since
>this mess of sysenter/syscall availability is not easy to understand to
>start with. Perhaps we should enumerate the full range of possibilities:
> 32app-on-32os-on32hv, 32app-on-32os-on-64hv, 32app-on-64os-on64-hv,
>64app-on-64os-on64hv

Hmm, I can do that, but it would seem more confusing to me than things
currently are.

>Also there is the orthogonal possibility of AMD vs. Intel. It would be
>useful to indicate clearly which options (syscall/sysenter) are available in
>which cases, and how this can be detected (e.g., through failure of setup
>hypercalls, and/or through CPUID bits, and/or by logic hardcoded in the
>guest OS).

There is cpuid-based detection in the guest, and in one case hypercall failure
based one, too. The only cheating I do is tying syscall32 setup availability to
the sysenter CPUID bit, since I can't look at the syscall bit (which was always
left alone on 64-bit hv).

>The 'compat' change to arch_set_info_guest() seems strange. Also the changes
>to vcpu_initialise(). If the guest has not set up appropriate

I have to do both of this to be backward compatible, i.e. deal with the case
that the guest doesn't use any of these hypercalls (in which case syscall from
a 32-bit app must [oddly enough] end up on the 64-bit entry point, eflags
must be masked just the way we traditionally did [plus the recent DF flag,
which is the only real significant bit set here as all others are anyway forced
off by create_bounce_frame]).

>sysenter/syscall callbacks, shouldn't we just default to something like #GP
>when syscall/sysenter is used?

That is the case. This is being checked in the entry.S stubs.

Jan


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

<Prev in Thread] Current Thread [Next in Thread>