From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: portability issues Date: Thu, 21 Jun 2007 09:10:37 +0100 Message-ID: <467A4E9D.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: 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: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Being in the process of trying to enable sysenter/syscall use from compat = mode guests and compat mode apps in native guests (for performance to a certain degree, but more importantly - at least for the compat mode app case - to = get closer to native behavior, i.e. mid/long term requiring less kernel = modifications) I'm facing a few backwards compatibility issues that I'm not really sure = how to deal with: 1) Obviously I need to extend the guest_context structure (to store the additional callback addresses), but there do not seem to be provisions to = do so without breaking the dom0 interface. I'm currently considering adding a flag indicating use of the larger structure, but this certainly doesn't = scale well considering future additions. An alternative might be to add a single flag covering all future additions, and using the first field past the current = size to store the overall or add-on size, so that the hypervisor has a way to know how much of the structure to copy. 2) While the x86-32 hv can't support syscall and is unlikely to support = sysenter, save/restore/migration (which hopefully will work at least from 32-bit hv = to 64-bit hv in the future) imposes an issue here in that native wouldn't = need these extra fields, but a compat mode guest would have to have a way to store them (in compat mode format), implying that guest_context would also need to be extended for 32-bits. 3) Currently, the 32-bit kernel check X86_FEATURE_SEP and the return status of setting the sysenter hypercall, to detect its availability when = run in supervisor mode. This, however, is being done only on the boot CPU, which works thanks to a quirk in how Xen handles the hypercall - MSRs for all CPUs get set by this single call, which clearly doesn't match native behavior (where in theory all CPUs could have distinct settings and have to establish them as they come up). The problem with this is that if = things turn out to work as intended, X86_FEATURE_SEP will be seen enabled by the guest when run on a 64-bit hv, and setting the sysenter callback will also succeed, but existing guests will fail to set the callback on all = CPUs. I have to admit that I'm rather reluctant to add the same kind of quirk = for !supervisor_mode_kernel in the hypervisor's handling of CALLBACK_sysenter. Thanks for suggestions/opinions, Jan