From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] x86-64: syscall/sysenter support for 32-bit apps Date: Thu, 05 Jul 2007 16:16:28 +0100 Message-ID: <468D276C.76E4.0078.0@novell.com> References: <468D094C.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 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 availabilit= y 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