aboutsummaryrefslogtreecommitdiffstats
path: root/xen/include/asm-x86/i387.h
Commit message (Collapse)AuthorAgeFilesLines
* x86: preserve FPU selectors for 32-bit guest codeJan Beulich2013-06-041-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Doing {,F}X{SAVE,RSTOR} unconditionally with 64-bit operand size leads to the selector values associated with the last instruction/data pointers getting lost. This, besides being inconsistent and not compatible with native hardware behavior especially for 32-bit guests, leads to bug checks in 32-bit Windows when running with "Driver verifier" (see e.g. http://support.microsoft.com/kb/244617). In a first try I made the code figure out the current guest mode, but that has the disadvantage of only taking care of the issue when the guest executes in the mode for which the state currently is (i.e. namely not in the case of a 64-bit guest running a 32-bit application, but being in kernle [64-bit] mode). The solution presented here is to conditionally execute an auxiliary FNSTENV and use the selectors from there. In either case the determined word size gets stored in the last byte of the FPU/SSE save area, which is available for software use (and I verified is being cleared to zero by all versions of Xen, i.e. will not present a problem when migrating guests from older to newer hosts), and evaluated for determining the operand size {,F}XRSTOR is to be issued with. Note that I did check whether using a second FXSAVE or a partial second XSAVE would be faster than FNSTENV - neither on my Westmere (FXSAVE) nor on my Romley (XSAVE) they are. I was really tempted to use branches into the middle of instructions (i.e. past the REX64 prefixes) here, as that would have allowed to collapse the otherwise identical fault recovery blocks. I stayed away from doing so just because I expect others to dislike such slightly subtle/tricky code. Reported-by: Ben Guthro <Benjamin.Guthro@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
* x86/fpu: create lazy and non-lazy FPU restore functionsWei Huang2011-05-091-1/+2
| | | | | | | | | | | | | Currently Xen relies on #NM (via CR0.TS) to trigger FPU context restore. But not all FPU state is tracked by TS bit. This function creates two FPU restore functions: vcpu_restore_fpu_lazy() and vcpu_restore_fpu_eager(). vcpu_restore_fpu_lazy() is still used when #NM is triggered. vcpu_restore_fpu_eager(), as a comparision, is called for vcpu which is being scheduled in on every context switch. To minimize restore overhead, it creates a flag, nonlazy_xstate_used, to control non-lazy restore. Signed-off-by: Wei Huang <wei.huang2@amd.com>
* x86/fpu: clean up FPU context restore functionWei Huang2011-05-091-1/+1
| | | | | | | | | This patch cleans up context restore function. It renames the function name to vcpu_restore_fpu(). It also extracts FPU restore code (frstor, fxrstor, xrstor) out into seperate functions. vcpu_restor_fpu() will dispatch to these functions depending on CPU's capability. Signed-off-by: Wei Huang <wei.huang2@amd.com>
* x86/fpu: clean up FPU context save functionWei Huang2011-05-091-1/+1
| | | | | | | | | | This patch cleans up context save function. It renames the save function to vcpu_save_fpu() because existing function name is confusion. It also extracts FPU context save code (fsave, fxsave, xsave) into seperate functions. vcpu_save_fpu() will call corresponding sub-function depending on CPU's capability. Signed-off-by: Wei Huang <wei.huang2@amd.com>
* x86/fpu: create FPU init and destroy functionsWei Huang2011-05-091-0/+2
| | | | | | | Extract FPU initialization and destroy code into two functions. These functions handle memory allocation/deallocation for FPU context. Signed-off-by: Wei Huang <wei.huang2@amd.com>
* x86/fpu: extract extended related code into xstate.h and xstate.cWei Huang2011-05-091-66/+2
| | | | | | | | | | Current extended code is mixing with FPU code in i387.c. As part of FPU code cleanup, this patch moves all extended state code into independent files. Not much semantic are changed and most function names are kept untouched, except for xsave() and xsaveopt(). These two functions are combined into a single function. Signed-off-by: Wei Huang <wei.huang2@amd.com>
* x86: add strictly sanity check for XSAVE/XRSTORWei Gang2011-02-211-2/+5
| | | | | | | | Replace most checks on cpu_has_xsave with checks on new fn xsave_enabled(), do additional sanity checks in the new fn. Signed-off-by: Wei Gang <gang.wei@intel.com> Signed-off-by: Keir Fraser <keir.xen@gmail.com>
* x86: reduce magic number usage in XSAVE codeWei Gang2011-02-091-1/+2
| | | | Signed-off-by: Wei Gang <gang.wei@intel.com>
* x86 fpu: Code clean up. Eliminate per-cpu xsave init verbosity.Keir Fraser2011-01-141-48/+0
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* x86: Avoid calling xsave_alloc_save_area before xsave_initKeir Fraser2011-01-141-31/+1
| | | | | | | | | | | | | | | Currently, xsave_alloc_save_area will be called in init_idle_domain->scheduler_init->alloc_vcpu->vcpu_initialise calls with xsave_cntxt_size=0, it is earlier than xsave_init called in identity_cpu(). This may causing buffer overflow on xmem_pool. Idle domain isn't using FPU,SSE,AVX or any such extended state and doesn't need it saved. xsave_{alloc,free}_save_area() should test-and-exit on is_idle_vcpu(), and our context switch code should not be doing XSAVE when switching out an idle vcpu. Signed-off-by: Wei Gang <gang.wei@intel.com> Signed-off-by: Keir Fraser <keir@xen.org>
* x86 xsave: Enable xsave_feature[62] (AMD Lightweight Profiling)Keir Fraser2010-12-241-4/+5
| | | | | | | The spec of LWP is available at http://developer.amd.com/cpu/lwp/Pages/default.aspx. Signed-off-by: Wei Huang <wei.huang2@amd.com>
* x86:xsaveopt: Enable xsaveopt feature in Xen and guestKeir Fraser2010-12-171-0/+14
| | | | | | | | This patch uses "xsaveopt" instead of "xsave" if the feature is supported in hardware to optimize task switch performance in Xen. It also exposes the feature to guest VMs. Signed-off-by: Zhang Fengzhe <fengzhe.zhang@intel.com>
* x86: Clean up vcpu initialisation (especially xsave save area)Keir Fraser2010-11-161-2/+3
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* x86: Xsave support for PV guests.Keir Fraser2010-11-031-5/+17
| | | | | Signed-off-by: Shan Haitao <haitao.shan@intel.com> Signed-off-by: Han Weidong <weidong.han@intel.com>
* x86: Clean up existing XSAVE supportKeir Fraser2010-10-291-14/+10
| | | | | Signed-off-by: Han Weidong <weidong.han@intel.com> Signed-off-by: Shan Haitao <haitao.shan@intel.com>
* vmx: add the support of XSAVE/XRSTOR to VMX guestKeir Fraser2009-09-291-3/+91
| | | | | | | | | | | | | | | XSAVE/XRSTOR manages the existing and future processor extended states on x86 architecture. The XSAVE/XRSTOR infrastructure is defined in Intel SDMs: http://www.intel.com/products/processor/manuals/ The patch uses the classical CR0.TS based algorithm to manage the states on context switch. At present, we know 3 bits in the XFEATURE_ENABLED_MASK: FPU, SSE and YMM. YMM is defined in Intel AVX Programming Reference: http://software.intel.com/sites/avx/ Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
* xen: Get rid of some VCPUF_* flags and move into their own byte fields.kfraser@localhost.localdomain2007-03-291-5/+6
| | | | Signed-off-by: Keir Fraser <keir@xensource.com>
* Fix to previous changeset: CLTS must be unconditional inkaf24@firebug.cl.cam.ac.uk2006-02-151-10/+11
| | | | | | | | | | setup_fpu(), as the flag can be set in CR0 even if the VCPU has already dirtied the FPU (this happens if a paravirtualised guest has set CR0.TS). Signed-off-by: Keir Fraser <keir@xensource.com>
* More fixes to HVM FPU management. Mostly for SVM, but alsokaf24@firebug.cl.cam.ac.uk2006-02-151-0/+1
| | | | | | | | | fix VMX mov_to_cr0: must setup_fpu() if the new cr0 value has TS clear, regardless of previous cr0.TS value. Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1644.1.1 (429f749dKFzVUg9NXDMVu4apHJvpNQ)kaf24@firebug.cl.cam.ac.uk2005-06-021-6/+6
| | | | | | | The last annoying rename: struct exec_domain *ed -> struct vcpu *v Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1389.20.1 (42836117f2yEkILParltXJcom3kTeA)kaf24@firebug.cl.cam.ac.uk2005-05-121-3/+3
| | | | | | | | | More descriptive 'flags' and 'id' field names for exec_domain/domain structures seems a good idea after all. At the same time, I've renamed the flag macros to be a bit neater and more descriptive, and more in keeping with the style of such definitions in asm/mm.h, for example. Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1389.15.17 (42826929NzXOK9PSr4_HoDheSjVx3A)cl349@firebug.cl.cam.ac.uk2005-05-111-0/+12
| | | | | | | | | | | vmx.h, i387.h, vmx_vmcs.c, vmx_io.c, vmx.c, traps.c: Implement a eager save/lazy restore algorithm for dealing with the FP state of a VMX guest. Signed-off-by: Xin B Li <xin.b.li@intel.com> Signed-off-by: Asit Mallick <asit.k.mallick@intel.com> Signed-off-by: Arun Sharma <arun.sharma@intel.com> Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
* bitkeeper revision 1.1389.5.35 (427e00b2juTv-JMiPdIYinvwaH2N8Q)kaf24@firebug.cl.cam.ac.uk2005-05-081-1/+1
| | | | | | Field-name cleanups. Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1236.1.1 (421bba88ZaitlU4qEVN6Xp2WKaq8Vg)kaf24@scramble.cl.cam.ac.uk2005-02-221-16/+9
| | | | | | FPU fixes. Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1159.1.393 (4190a145cbZFKzGdkH5xPlOlxNNPnw)cl349@freefall.cl.cam.ac.uk2004-11-091-4/+4
| | | | | Split struct exec_domain out of struct domain.
* bitkeeper revision 1.982 (40d300456_XUbFFOMxRh4MjyB7AfJA)kaf24@scramble.cl.cam.ac.uk2004-06-181-4/+4
| | | | | | | | | Hacked the scheduler interfaces in Xen. We now have synchronous pause. Suspend/death VIRQs have gone away; replace by dom-controller msgs. Xen no longer knows about PS/2 keyboard/mouse; DOM0 can go straight at them.
* bitkeeper revision 1.952 (40c8935a3XSRdQfnx5RoO7XgaggvOQ)kaf24@scramble.cl.cam.ac.uk2004-06-101-0/+38
Towards x86_64 support. Merged a bunch of the existing x86_64 stuff back into a generic 'x86' architecture. Aim is to share as much as possible between 32- and 64-bit worlds.