[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86-64: syscall/sysenter support for 32-bit apps
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |