- 06 Jul, 2014 1 commit
-
-
Aneesh Kumar K.V authored
We use time base for PURR and SPURR emulation with PR KVM since we are emulating a single threaded core. When using time base we need to make sure that we don't accumulate time spent in the host in PURR and SPURR value. Also we don't need to emulate mtspr because both the registers are hypervisor resource. Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Alexander Graf <agraf@suse.de>
-
- 30 Jun, 2014 11 commits
-
-
Rickard Strandqvist authored
A struct member variable is set to the same value more than once This was found using a static code analysis program called cppcheck. Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Deng-Cheng Zhu authored
It's impossible to fall into the error handling of the TLB index after being masked by (KVM_MIPS_GUEST_TLB_SIZE - 1). Remove the dead code. Reported-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Deng-Cheng Zhu <dengcheng.zhu@imgtec.com> Reviewed-by:
-
Deng-Cheng Zhu authored
The commpage is allocated using kzalloc(), so there's no need of cleaning the memory of the kvm_mips_commpage struct and its internal mips_coproc. Reviewed-by:
-
Deng-Cheng Zhu authored
Since all the files are in arch/mips/kvm/, there's no need of the prefixes "kvm_" and "kvm_mips_". Reviewed-by:
-
Deng-Cheng Zhu authored
The keyword volatile for idx in the TLB functions is unnecessary. Reviewed-by:
-
Deng-Cheng Zhu authored
No logic changes inside. Reviewed-by:
-
Deng-Cheng Zhu authored
Replace printks with kvm_[err|info|debug]. Signed-off-by:
-
Deng-Cheng Zhu authored
No logic changes inside. Signed-off-by:
-
Paolo Bonzini authored
Merge tag 'kvms390-20140626' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD Fix sie.h header related problems introduced during the 3.16 development cycle.
-
Paolo Bonzini authored
Fix bad x86 regression introduced during merge window.
-
Jan Kiszka authored
We import the CPL via SS.DPL since ae9fedc7. However, we fail to export it this way so far. This caused spurious guest crashes, e.g. of Linux when accessing the vmport from guest user space which triggered register saving/restoring to/from host user space. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
-
- 26 Jun, 2014 1 commit
-
-
Heiko Carstens authored
sie.h was missing in arch/s390/include/uapi/asm/Kbuild and therefore missed the "make headers_check" target. If added it reveals that also arch/s390/include/asm/sigp.h would become uapi. This is something we certainly do not want. So remove that dependency as well. The header file was merged with ceae283b "KVM: s390: add sie exit reasons tables", therefore we never had a kernel release with this commit and can still change anything. Acked-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com>
-
- 19 Jun, 2014 18 commits
-
-
Nadav Amit authored
VMX instructions use 32-bit operands in 32-bit mode, and 64-bit operands in 64-bit mode. The current implementation is broken since it does not use the register operands correctly, and always uses 64-bit for reads and writes. Moreover, write to memory in vmwrite only considers long-mode, so it ignores cs.l. This patch fixes this behavior. Signed-off-by:
Nadav Amit <namit@cs.technion.ac.il> Signed-off-by:
-
Nadav Amit authored
On 32-bit mode only bits [31:0] of the CR should be used for setting the CR value. Otherwise, the host may incorrectly assume the value is invalid if bits [63:32] are not zero. Moreover, the CR is currently being read twice when CR8 is used. Last, nested mov-cr exiting is modified to handle the CR value correctly as well. Signed-off-by:
-
Nadav Amit authored
Currently, the hypercall handling routine only considers LME as an indication to whether the guest uses 32/64-bit mode. This is incosistent with hyperv hypercalls handling and against the common sense of considering cs.l as well. This patch uses is_64_bit_mode instead of is_long_mode for that matter. In addition, the result is masked in respect to the guest execution mode. Last, it changes kvm_hv_hypercall to use is_64_bit_mode as well to simplify the code. Signed-off-by:
-
Nadav Amit authored
When the guest sets DR6 and DR7, KVM asserts the high 32-bits are clear, and otherwise injects a #GP exception. This exception should only be injected only if running in long-mode. Signed-off-by:
-
Jan Kiszka authored
Many real CPUs get this wrong as well, but ours is totally off: bits 9:1 define the highest index value. Signed-off-by:
-
Jan Kiszka authored
Allow L1 to "leak" its debug controls into L2, i.e. permit cleared VM_{ENTRY_LOAD,EXIT_SAVE}_DEBUG_CONTROLS. This requires to manually transfer the state of DR7 and IA32_DEBUGCTLMSR from L1 into L2 as both run on different VMCS. Signed-off-by: -
Jan Kiszka authored
SDM says bits 1, 4-6, 8, 13-16, and 26 have to be set. Signed-off-by:
-
Jan Kiszka authored
We already have this control enabled by exposing a broken MSR_IA32_VMX_PROCBASED_CTLS value. This will properly advertise our capability once the value is fixed by clearing the right bits in MSR_IA32_VMX_TRUE_PROCBASED_CTLS. We also have to ensure to test the right value on L2 entry. Signed-off-by:
-
Jan Kiszka authored
We already implemented them but failed to advertise them. Currently they all return the identical values to the capability MSRs they are augmenting. So there is no change in exposed features yet. Drop related comments at this chance that are partially incorrect and redundant anyway. Signed-off-by:
-
Jan Kiszka authored
The spec says those controls are at bit position 2 - makes 4 as value. The impact of this mistake is effectively zero as we only use them to ensure that these features are set at position 2 (or, previously, 1) in MSR_IA32_VMX_{EXIT,ENTRY}_CTLS - which is and will be always true according to the spec. Signed-off-by: -
Nadav Amit authored
On long-mode the current NOP (0x90) emulation still writes back to RAX. As a result, EAX is zero-extended and the high 32-bits of RAX are cleared. Signed-off-by:
-
Nadav Amit authored
Even if the condition of cmov is not satisfied, bits[63:32] should be cleared. This is clearly stated in Intel's CMOVcc documentation. The solution is to reassign the destination onto itself if the condition is unsatisfied. For that matter the original destination value needs to be read. Signed-off-by:
-
Nadav Amit authored
Return unhandlable error on inter-privilege level ret instruction. This is since the current emulation does not check the privilege level correctly when loading the CS, and does not pop RSP/SS as needed. Cc: stable@vger.kernel.org Signed-off-by:
-
Nadav Amit authored
The emulator does not emulate the xadd instruction correctly if the two operands are the same. In this (unlikely) situation the result should be the sum of X and X (2X) when it is currently X. The solution is to first perform writeback to the source, before writing to the destination. The only instruction which should be affected is xadd, as the other instructions that perform writeback to the source use the extended accumlator (e.g., RAX:RDX). Signed-off-by:
-
Nadav Amit authored
The current emulation of bit operations ignores the offset from the destination on 64-bit target memory operands. This patch fixes this behavior. Signed-off-by:
-
Fabian Frederick authored
use mm.h definition Cc: Gleb Natapov <gleb@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Paolo Bonzini authored
It was using the wrong member of the union. Signed-off-by: -
Paolo Bonzini authored
Memory is always the destination for BitOp instructions. Signed-off-by:
-
- 18 Jun, 2014 9 commits
-
-
Paolo Bonzini authored
We did not do that when interruptibility was added to the emulator, because at the time pop to segment was not implemented. Now it is, add it. Signed-off-by: -
Nadav Amit authored
In 64-bit mode, when the destination is a register, the assignment is done according to the operand size. Otherwise (memory operand or no 64-bit mode), a 16-bit assignment is performed. Currently, 16-bit assignment is always done to the destination. Signed-off-by:
-
Nadav Amit authored
cmpxchg16b is currently unimplemented in the emulator. The least we can do is return error upon the emulation of this instruction. Signed-off-by:
-
Nadav Amit authored
The rdpmc emulation checks that the counter (ECX) is not higher than 2, without taking into considerations bits 30:31 role (e.g., bit 30 marks whether the counter is fixed). The fix uses the pmu information for checking the validity of the pmu counter. Signed-off-by:
-
Nadav Amit authored
If the operand-size prefix (0x66) is used in 64-bit mode, the emulator would assume the destination operand is 64-bit, when it should be 32-bit. Reminder: movnti does not support 16-bit operands and its default operand size is 32-bit. Signed-off-by:
-
Nadav Amit authored
The current implementation of cmpxchg does not update the flags correctly, since the accumulator should be compared with the destination and not the other way around. The current implementation does not update the flags correctly. Signed-off-by:
-
Nadav Amit authored
The SGDT and SIDT instructions are not privilaged, i.e. they can be executed with CPL>0. Signed-off-by:
-
Nadav Amit authored
The current emulator implementation ignores the high 32 bits of the base in long-mode. During segment load from the LDT, the base of the LDT is calculated incorrectly and may cause the wrong segment to be loaded. Signed-off-by:
-
Nadav Amit authored
The current implementation ignores the LDTR/TR base high 32-bits on long-mode. As a result the loaded segment descriptor may be incorrect. Signed-off-by:
-
