- 27 Mar, 2015 27 commits
-
-
James Hogan authored
Add KVM register numbers for the MIPS FPU registers, and implement access to them with the KVM_GET_ONE_REG / KVM_SET_ONE_REG ioctls when the FPU capability is enabled (exposed in a later patch) and present in the guest according to its Config1.FP bit. The registers are accessible in the current mode of the guest, with each sized access showing what the guest would see with an equivalent access, and like the architecture they may become UNPREDICTABLE if the FR mode is changed. When FR=0, odd doubles are inaccessible as they do not exist in that mode. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Gleb Natapov <gleb@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Cc: linux-api@vger.kernel.org Cc: linux-doc@vger.kernel.org
-
James Hogan authored
Add guest exception handling for floating point exceptions and coprocessor 1 unusable exceptions. Floating point exceptions from the guest need passing to the guest kernel, so for these a guest FPE is emulated. Also, coprocessor 1 unusable exceptions are normally passed straight through to the guest (because no guest FPU was supported), but the hypervisor can now handle them if the guest has its FPU enabled by restoring the guest FPU context and enabling the FPU. Signed-off-by: -
James Hogan authored
Emulate FPU related parts of COP0 interface so that the guest will be able to enable/disable the following once the FPU capability has been wired up: - The FPU (Status.CU1) - 64-bit FP register mode (Status.FR) - Hybrid FP register mode (Config5.FRE) Changing Status.CU1 has no immediate effect if the FPU state isn't live, as the FPU state is restored lazily on first use. After that, changes take place immediately in the host Status.CU1, so that the guest can start getting coprocessor unusable exceptions right away for guest FPU operations if it is disabled. The FPU state is saved lazily too, as the FPU may get re-enabled in the near future anyway. Any change to Status.FR causes the FPU state to be discarded and FPU disabled, as the register state is architecturally UNPREDICTABLE after such a change. This should also ensure that the FPU state is fully initialised (with stale state, but that's fine) when it is next used in the new FP mode. Any change to the Config5.FRE bit is immediately updated in the host state so that the guest can get the relevant exceptions right away for single-precision FPU operations. Signed-off-by: -
James Hogan authored
Add base code for supporting FPU in MIPS KVM guests. The FPU cannot yet be enabled in the guest, we're just laying the groundwork. Whether the guest's FPU context is loaded is stored in a bit in the fpu_inuse vcpu member. This allows the FPU to be disabled when the guest disables it, but keeping the FPU context loaded so it doesn't have to be reloaded if the guest re-enables it. An fpu_enabled vcpu member stores whether userland has enabled the FPU capability (which will be wired up in a later patch). New assembly code is added for saving and restoring the FPU context, and for saving/clearing and restoring FCSR (which can itself cause an FP exception depending on the value). The FCSR is restored before returning to the guest if the FPU is already enabled, and a die notifier is registered to catch the possible FP exception and step over the ctc1 instruction. The helper function kvm_lose_fpu() is added to save FPU context and disable the FPU, which is used when saving hardware state before a context switch or KVM exit (the vcpu_get_regs() callback). The helper function kvm_own_fpu() is added to enable the FPU and restore the FPU context if it isn't already loaded, which will be used in a later patch when the guest attempts to use the FPU for the first time and triggers a co-processor unusable exception. The helper function kvm_drop_fpu() is added to discard the FPU context and disable the FPU, which will be used in a later patch when the FPU state will become architecturally UNPREDICTABLE (change of FR mode) to force a reload of [stale] context in the new FR mode. Signed-off-by: -
James Hogan authored
Add a vcpu_get_regs() and vcpu_set_regs() callbacks for loading and restoring context which may be in hardware registers. This may include floating point and MIPS SIMD Architecture (MSA) state which may be accessed directly by the guest (but restored lazily by the hypervisor), and also dedicated guest registers as provided by the VZ ASE. Signed-off-by: -
James Hogan authored
Add Config4 and Config5 co-processor 0 registers, and add capability to write the Config1, Config3, Config4, and Config5 registers using the KVM API. Only supported bits can be written, to minimise the chances of the guest being given a configuration from e.g. QEMU that is inconsistent with that being emulated, and as such the handling is in trap_emul.c as it may need to be different for VZ. Currently the only modification permitted is to make Config4 and Config5 exist via the M bits, but other bits will be added for FPU and MSA support in future patches. Care should be taken by userland not to change bits without fully handling the possible extra state that may then exist and which the guest may begin to use and depend on. Signed-off-by: -
James Hogan authored
Various semi-used definitions exist in kvm_host.h for the default guest config registers. Remove them and use the appropriate values directly when initialising the Config registers. Signed-off-by: -
James Hogan authored
Clean up KVM_GET_ONE_REG / KVM_SET_ONE_REG register definitions for MIPS, to prepare for adding a new group for FPU & MSA vector registers. Definitions are added for common bits in each group of registers, e.g. KVM_REG_MIPS_CP0 = KVM_REG_MIPS | 0x10000, for the coprocessor 0 registers. Signed-off-by: -
James Hogan authored
The information messages when the KVM module is loaded and unloaded are a bit pointless and out of line with other architectures, so lets drop them. Signed-off-by: -
James Hogan authored
Sort the registers in the kvm_mips_get_reg() switch by register number, which puts ERROREPC after the CONFIG registers. Signed-off-by: -
James Hogan authored
Implement access to the guest Processor Identification CP0 register using the KVM_GET_ONE_REG and KVM_SET_ONE_REG ioctls. This allows the owning process to modify and read back the value that is exposed to the guest in this register. Signed-off-by: -
James Hogan authored
Trap instructions are used by Linux to implement BUG_ON(), however KVM doesn't pass trap exceptions on to the guest if they occur in guest kernel mode, instead triggering an internal error "Exception Code: 13, not yet handled". The guest kernel then doesn't get a chance to print the usual BUG message and stack trace. Implement handling of the trap exception so that it gets passed to the guest and the user is left with a more useful log message. Signed-off-by: -
James Hogan authored
When handling floating point exceptions (FPEs) and MSA FPEs the Cause bits of the appropriate control and status register (FCSR for FPEs and MSACSR for MSA FPEs) are read and cleared before enabling interrupts, presumably so that it doesn't have to go through the pain of restoring those bits if the process is pre-empted, since writing those bits would cause another immediate exception while still in the kernel. The bits aren't normally ever restored again, since userland never expects to see them set. However for virtualisation it is necessary for the kernel to be able to restore these Cause bits, as the guest may have been interrupted in an FP exception handler but before it could read the Cause bits. This can be done by registering a die notifier, to get notified of the exception when such a value is restored, and if the PC was at the instruction which is used to restore the guest state, the handler can step over it and continue execution. The Cause bits can then remain set without causing further exceptions. For this to work safely a few changes are made: - __build_clear_fpe and __build_clear_msa_fpe no longer clear the Cause bits, and now return from exception level with interrupts disabled instead of enabled. - do_fpe() now clears the Cause bits and enables interrupts after notify_die() is called, so that the notifier can chose to return from exception without this happening. - do_msa_fpe() acts similarly, but now actually makes use of the second argument (msacsr) and calls notify_die() with the new DIE_MSAFP, allowing die notifiers to be informed of MSA FPEs too. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org
-
James Hogan authored
Guest user mode can generate a guest MSA Disabled exception on an MSA capable core by simply trying to execute an MSA instruction. Since this exception is unknown to KVM it will be passed on to the guest kernel. However guest Linux kernels prior to v3.15 do not set up an exception handler for the MSA Disabled exception as they don't support any MSA capable cores. This results in a guest OS panic. Since an older processor ID may be being emulated, and MSA support is not advertised to the guest, the correct behaviour is to generate a Reserved Instruction exception in the guest kernel so it can send the guest process an illegal instruction signal (SIGILL), as would happen with a non-MSA-capable core. Fix this as minimally as reasonably possible by preventing kvm_mips_check_privilege() from relaying MSA Disabled exceptions from guest user mode to the guest kernel, and handling the MSA Disabled exception by emulating a Reserved Instruction exception in the guest, via a new handle_msa_disabled() KVM callback. Signed-off-by: -
git://git.linux-mips.org/pub/scm/ralf/upstream-sfrJames Hogan authored
MIPS FP/MSA fixes from the MIPS tree. Includes a fix to ensure that the FPU is properly disabled by lose_fpu() when MSA is in use, and Paul Burton's "FP/MSA fixes" patchset which is required for FP/MSA support in KVM: > This series fixes a bunch of bugs, both build & runtime, with FP & MSA > support. Most of them only affect systems with the new FP modes & MSA > support enabled but patch 6 in particular is more general, fixing > problems for mips64 systems.
-
James Hogan authored
The maximum word size is 64-bits since MSA state is saved using st.d which stores two 64-bit words, therefore reimplement FPR_IDX using xor, and only within each 64-bit word. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9169/Signed-off-by:
-
James Hogan authored
This reverts commit 02987633. The basic premise of the patch was incorrect since MSA context (including FP state) is saved using st.d which stores two consecutive 64-bit words in memory rather than a single 128-bit word. This means that even with big endian MSA, the FP state is still in the first 64-bit word. Signed-off-by:
-
Paul Burton authored
The expected semantics of __enable_fpu are for the FPU to be enabled in the given mode if possible, otherwise for the FPU to be left disabled and SIGFPE returned. The FPU was incorrectly being left enabled in cases where the desired value for FR was unavailable. Without ensuring the FPU is disabled in this case, it would be possible for userland to go on to execute further FP instructions natively in the incorrect mode, rather than those instructions being trapped & emulated as they need to be. Signed-off-by:
-
Paul Burton authored
If a ptracee has not used the FPU and the ptracer sets its FP context using PTRACE_POKEUSR, PTRACE_SETFPREGS or PTRACE_SETREGSET then that context will be discarded upon either the ptracee using the FPU or a further write to the context via ptrace. Prevent this loss by recording that the task has "used" math once its FP context has been written to. The context initialisation code that was present for the PTRACE_POKEUSR case is reused for the other 2 cases to provide consistent behaviour for the different ptrace requests. Signed-off-by:
-
Paul Burton authored
When running the emulator to handle an instruction that raised an FP unimplemented operation exception, the FCSR cause bits were being cleared. This is done to ensure that the kernel does not take an FP exception when later restoring FP context to registers. However, this was not being done when the emulator is invoked in response to a coprocessor unusable exception. This happens in 2 cases: - There is no FPU present in the system. In this case things were OK, since the FP context is never restored to hardware registers and thus no FP exception may be raised when restoring FCSR. - The FPU could not be configured to the mode required by the task. In this case it would be possible for the emulator to set cause bits which are later restored to hardware if the task migrates to a CPU whose associated FPU does support its mode requirements, or if the tasks FP mode requirements change. Consistently clear the cause bits after invoking the emulator, by moving the clearing to process_fpemu_return and ensuring this is always called before the tasks FP context is restored. This will make it easier to catch further paths invoking the emulator in future, as will be introduced in further patches. Signed-off-by: -
Paul Burton authored
Much like for traditional scalar FP exceptions, the cause bits in the MSACSR register need to be cleared following an MSA FP exception. Without doing so the exception will simply be raised again whenever the kernel restores MSACSR from a tasks saved context, leading to undesirable spurious exceptions. Clear the cause bits from the handle_msa_fpe function, mirroring the way handle_fpe clears the cause bits in FCSR. Signed-off-by:
-
Paul Burton authored
Uses of the cfcmsa & ctcmsa instructions were not being wrapped by a macro in the case where the toolchain supports MSA, since the arguments exactly match a typical use of the instructions. However using current toolchains this leads to errors such as: arch/mips/kernel/genex.S:437: Error: opcode not supported on this processor: mips32r2 (mips32r2) `cfcmsa $5,1' Thus uses of the instructions must be in the context of a ".set msa" directive, however doing that from the users of the instructions would be messy due to the possibility that the toolchain does not support MSA. Fix this by renaming the macros (prepending an underscore) in order to avoid recursion when attempting to emit the instructions, and provide implementations for the TOOLCHAIN_SUPPORTS_MSA case which ".set msa" as appropriate. Signed-off-by:
-
Paul Burton authored
Recursive macros made the code more concise & worked great for the case where the toolchain doesn't support MSA. However, with toolchains which do support MSA they lead to build failures such as: arch/mips/kernel/r4k_switch.S: Assembler messages: arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[2],$1' arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[3],$1' arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[2],$1' arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[3],$1' ... Drop the recursion from msa_init_all_upper invoking the msa_init_upper macro explicitly for each vector register. Signed-off-by:
-
Paul Burton authored
Assuming at ($1) as the source or destination register of copy or insert instructions: - Simplifies the macros providing those instructions for toolchains without MSA support. - Avoids an unnecessary move instruction when at is used as the source or destination register anyway. - Is sufficient for the uses to be introduced in the kernel by a subsequent patch. Note that due to a patch ordering snafu on my part this also fixes the currently broken build with MSA support enabled. The build has been broken since commit c9017757 "MIPS: init upper 64b of vector registers when MSA is first used", which this patch should have preceeded. Signed-off-by: -
Paul Burton authored
The {save,restore}_fp_context{,32} functions require that the assembler allows the use of sdc instructions on any FP register, and this is acomplished by setting the arch to mips64r2 or mips64r6 (using MIPS_ISA_ARCH_LEVEL_RAW). However this has the effect of enabling the assembler to use mips64 instructions in the expansion of pseudo-instructions. This was done in the (now-reverted) commit eec43a22 "MIPS: Save/restore MSA context around signals" which led to my mistakenly believing that there was an assembler bug, when in reality the assembler was just emitting mips64 instructions. Avoid the issue for future commits which will add code to r4k_fpu.S by pushing the .set MIPS_ISA_ARCH_LEVEL_RAW directives into the functions that require it, and remove the spurious assertion declaring the assembler bug. Signed-off-by: -
James Hogan authored
The lose_fpu() function only disables the FPU in CP0_Status.CU1 if the FPU is in use and MSA isn't enabled. This isn't necessarily a problem because KSTK_STATUS(current), the version of CP0_Status stored on the kernel stack on entry from user mode, does always get updated and gets restored when returning to user mode, but I don't think it was intended, and it is inconsistent with the case of only the FPU being in use. Sometimes leaving the FPU enabled may also mask kernel bugs where FPU operations are executed when the FPU might not be enabled. So lets disable the FPU in the MSA case too. Fixes: 33c771ba ("MIPS: save/disable MSA in lose_fpu") Signed-off-by:
-
Jan Kiszka authored
If the guest CPU is supposed to support rdtscp and the host has rdtscp enabled in the secondary execution controls, we can also expose this feature to L1. Just extend nested_vmx_exit_handled to properly route EXIT_REASON_RDTSCP. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- 24 Mar, 2015 1 commit
-
-
Radim Krčmář authored
An overhead from function call is not appropriate for its size and frequency of execution. Suggested-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
- 23 Mar, 2015 2 commits
-
-
Marcelo Tosatti authored
Merge tag 'kvm-s390-next-20150318' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into queue KVM: s390: Features and fixes for 4.1 (kvm/next) 1. Fixes 2. Implement access register mode in KVM 3. Provide a userspace post handler for the STSI instruction 4. Provide an interface for compliant memory accesses 5. Provide an interface for getting/setting the guest storage key 6. Fixup for the vector facility patches: do not announce the vector facility in the guest for old QEMUs. 1-5 were initially shown as RFC in http://www.spinics.net/lists/kvm/msg114720.html some small review changes - added some ACKs - have the AR mode patches first - get rid of unnecessary AR_INVAL define - typos and language 6. two new patches The two new patches fixup the vector support patches that were introduced in the last pull request for QEMU versions that dont know about vector support and guests that do. (We announce the facility bit, but dont enable the facility so vector aware guests will crash on vector instructions).
-
Marcelo Tosatti authored
The following point: 2. per-CPU pvclock time info is updated if the underlying CPU changes. Is not true anymore since "KVM: x86: update pvclock area conditionally, on cpu migration". Add task migration notification back. Problem noticed by Andy Lutomirski. Signed-off-by:
-
- 19 Mar, 2015 2 commits
-
-
Takuya Yoshikawa authored
When all bits in mask are not set, kvm_arch_mmu_enable_log_dirty_pt_masked() has nothing to do. But since it needs to be called from the generic code, it cannot be inlined, and a few function calls, two when PML is enabled, are wasted. Since it is common to see many pages remain clean, e.g. framebuffers can stay calm for a long time, it is worth eliminating this overhead. Signed-off-by:
Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp> Reviewed-by:
-
Bandan Das authored
I hit this path on a AMD box and thought someone was playing a April Fool's joke on me. Signed-off-by:
Bandan Das <bsd@redhat.com> Signed-off-by:
-
- 18 Mar, 2015 2 commits
-
-
Xiubo Li authored
This patch fix the following sparse warnings: for arch/x86/kvm/x86.c: warning: symbol 'emulator_read_write' was not declared. Should it be static? warning: symbol 'emulator_write_emulated' was not declared. Should it be static? warning: symbol 'emulator_get_dr' was not declared. Should it be static? warning: symbol 'emulator_set_dr' was not declared. Should it be static? for arch/x86/kvm/pmu.c: warning: symbol 'fixed_pmc_events' was not declared. Should it be static? Signed-off-by:
Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by:
-
Xiubo Li authored
This patch fix the following sparse warning: for file arch/x86/kvm/x86.c: warning: Using plain integer as NULL pointer Signed-off-by:
-
- 17 Mar, 2015 6 commits
-
-
Michael Mueller authored
The patch represents capability KVM_CAP_S390_VECTOR_REGISTERS by means of the SIMD facility bit. This allows to a) disable the use of SIMD when used in conjunction with a not-SIMD-aware QEMU, b) to enable SIMD when used with a SIMD-aware version of QEMU and c) finally by means of a QEMU version using the future cpu model ioctls. Signed-off-by:
Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by:
Eric Farman <farman@linux.vnet.ibm.com> Tested-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com>
-
Michael Mueller authored
Setting the SIMD bit in the KVM mask is an issue because it makes the facility visible but not usable to the guest, thus it needs to be removed again. Signed-off-by:
-
Jason J. Herne authored
Provide the KVM_S390_GET_SKEYS and KVM_S390_SET_SKEYS ioctl which can be used to get/set guest storage keys. This functionality is needed for live migration of s390 guests that use storage keys. Signed-off-by:
Jason J. Herne <jjherne@linux.vnet.ibm.com> Reviewed-by:
-
Ekaterina Tumanova authored
The Store System Information (STSI) instruction currently collects all information it relays to the caller in the kernel. Some information, however, is only available in user space. An example of this is the guest name: The kernel always sets "KVMGuest", but user space knows the actual guest name. This patch introduces a new exit, KVM_EXIT_S390_STSI, guarded by a capability that can be enabled by user space if it wants to be able to insert such data. User space will be provided with the target buffer and the requested STSI function code. Reviewed-by:
Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> Signed-off-by:
-
Thomas Huth authored
On s390, we've got to make sure to hold the IPTE lock while accessing logical memory. So let's add an ioctl for reading and writing logical memory to provide this feature for userspace, too. The maximum transfer size of this call is limited to 64kB to prevent that the guest can trigger huge copy_from/to_user transfers. QEMU currently only requests up to one or two pages so far, so 16*4kB seems to be a reasonable limit here. Signed-off-by:
Thomas Huth <thuth@linux.vnet.ibm.com> Signed-off-by:
-
Alexander Yarygin authored
Access register mode is one of the modes that control dynamic address translation. In this mode the address space is specified by values of the access registers. The effective address-space-control element is obtained from the result of the access register translation. See the "Access-Register Introduction" section of the chapter 5 "Program Execution" in "Principles of Operations" for more details. Signed-off-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Reviewed-by:
-
