aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/kvm/mtrr.c
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15KVM: x86: remove bogus #GP injectionPaolo Bonzini1-5/+1
There is no need to inject a #GP from kvm_mtrr_set_msr, kvm_emulate_wrmsr will handle it. Reviewed-by: Tom Lendacky <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-01-27KVM: x86: Protect MSR-based index computations in fixed_msr_to_seg_unit() ↵Marios Pomonis1-2/+6
from Spectre-v1/L1TF attacks This fixes a Spectre-v1/L1TF vulnerability in fixed_msr_to_seg_unit(). This function contains index computations based on the (attacker-controlled) MSR number. Fixes: de9aef5e1ad6 ("KVM: MTRR: introduce fixed_mtrr_segment table") Signed-off-by: Nick Finco <[email protected]> Signed-off-by: Marios Pomonis <[email protected]> Reviewed-by: Andrew Honig <[email protected]> Cc: [email protected] Reviewed-by: Jim Mattson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 499Thomas Gleixner1-3/+1
Based on 1 normalized pattern(s): this work is licensed under the terms of the gnu gpl version 2 see the copying file in the top level directory extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 35 file(s). Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Kate Stewart <[email protected]> Reviewed-by: Enrico Weigelt <[email protected]> Reviewed-by: Allison Randal <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-04-16KVM: x86: optimize check for valid PAT valuePaolo Bonzini1-9/+1
This check will soon be done on every nested vmentry and vmexit, "parallelize" it using bitwise operations. Reviewed-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2017-08-07KVM: x86: generalize guest_cpuid_has_ helpersRadim Krčmář1-1/+1
This patch turns guest_cpuid_has_XYZ(cpuid) into guest_cpuid_has(cpuid, X86_FEATURE_XYZ), which gets rid of many very similar helpers. When seeing a X86_FEATURE_*, we can know which cpuid it belongs to, but this information isn't in common code, so we recreate it for KVM. Add some BUILD_BUG_ONs to make sure that it runs nicely. Signed-off-by: Radim Krčmář <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2016-07-05KVM: MTRR: fix kvm_mtrr_check_gfn_range_consistency page faultAlexis Dambricourt1-0/+1
The following #PF may occurs: [ 1403.317041] BUG: unable to handle kernel paging request at 0000000200000068 [ 1403.317045] IP: [<ffffffffc04c20b0>] __mtrr_lookup_var_next+0x10/0xa0 [kvm] [ 1403.317123] Call Trace: [ 1403.317134] [<ffffffffc04c2a65>] ? kvm_mtrr_check_gfn_range_consistency+0xc5/0x120 [kvm] [ 1403.317143] [<ffffffffc04ac11f>] ? tdp_page_fault+0x9f/0x2c0 [kvm] [ 1403.317152] [<ffffffffc0498128>] ? kvm_set_msr_common+0x858/0xc00 [kvm] [ 1403.317161] [<ffffffffc04b8883>] ? x86_emulate_insn+0x273/0xd30 [kvm] [ 1403.317171] [<ffffffffc04c04e4>] ? kvm_cpuid+0x34/0x190 [kvm] [ 1403.317180] [<ffffffffc04a5bb9>] ? kvm_mmu_page_fault+0x59/0xe0 [kvm] [ 1403.317183] [<ffffffffc0d729e1>] ? vmx_handle_exit+0x1d1/0x14a0 [kvm_intel] [ 1403.317185] [<ffffffffc0d75f3f>] ? atomic_switch_perf_msrs+0x6f/0xa0 [kvm_intel] [ 1403.317187] [<ffffffffc0d7621d>] ? vmx_vcpu_run+0x2ad/0x420 [kvm_intel] [ 1403.317196] [<ffffffffc04a0962>] ? kvm_arch_vcpu_ioctl_run+0x622/0x1550 [kvm] [ 1403.317204] [<ffffffffc049abb9>] ? kvm_arch_vcpu_load+0x59/0x210 [kvm] [ 1403.317206] [<ffffffff81036245>] ? __kernel_fpu_end+0x35/0x100 [ 1403.317213] [<ffffffffc0487eb6>] ? kvm_vcpu_ioctl+0x316/0x5d0 [kvm] [ 1403.317215] [<ffffffff81088225>] ? do_sigtimedwait+0xd5/0x220 [ 1403.317217] [<ffffffff811f84dd>] ? do_vfs_ioctl+0x9d/0x5c0 [ 1403.317224] [<ffffffffc04928ae>] ? kvm_on_user_return+0x3e/0x70 [kvm] [ 1403.317225] [<ffffffff811f8a74>] ? SyS_ioctl+0x74/0x80 [ 1403.317227] [<ffffffff815bf0b6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 1403.317242] RIP [<ffffffffc04c20b0>] __mtrr_lookup_var_next+0x10/0xa0 [kvm] At mtrr_lookup_fixed_next(), when the condition 'if (iter->index >= ARRAY_SIZE(iter->mtrr_state->fixed_ranges))' becomes true, mtrr_lookup_var_start() is called with iter->range with gargabe values from the fixed MTRR union field. Then, list_prepare_entry() do not call list_entry() initialization, keeping a garbage pointer in iter->range which is accessed in the following __mtrr_lookup_var_next() call. Fixes: f571c0973e4b8c888e049b6842e4b4f93b5c609c Signed-off-by: Alexis Dambricourt <[email protected]> Cc: [email protected] Signed-off-by: Paolo Bonzini <[email protected]>
2016-05-18KVM: MTRR: remove MSR 0x2f8Andy Honig1-2/+0
MSR 0x2f8 accessed the 124th Variable Range MTRR ever since MTRR support was introduced by 9ba075a664df ("KVM: MTRR support"). 0x2f8 became harmful when 910a6aae4e2e ("KVM: MTRR: exactly define the size of variable MTRRs") shrinked the array of VR MTRRs from 256 to 8, which made access to index 124 out of bounds. The surrounding code only WARNs in this situation, thus the guest gained a limited read/write access to struct kvm_arch_vcpu. 0x2f8 is not a valid VR MTRR MSR, because KVM has/advertises only 16 VR MTRR MSRs, 0x200-0x20f. Every VR MTRR is set up using two MSRs, 0x2f8 was treated as a PHYSBASE and 0x2f9 would be its PHYSMASK, but 0x2f9 was not implemented in KVM, therefore 0x2f8 could never do anything useful and getting rid of it is safe. This fixes CVE-2016-3713. Fixes: 910a6aae4e2e ("KVM: MTRR: exactly define the size of variable MTRRs") Cc: [email protected] Reported-by: David Matlack <[email protected]> Signed-off-by: Andy Honig <[email protected]> Signed-off-by: Radim Krčmář <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-12-22KVM: MTRR: treat memory as writeback if MTRR is disabled in guest CPUIDPaolo Bonzini1-3/+11
Virtual machines can be run with CPUID such that there are no MTRRs. In that case, the firmware will never enable MTRRs and it is obviously undesirable to run the guest entirely with UC memory. Check out guest CPUID, and use WB memory if MTRR do not exist. Cc: [email protected] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561 Signed-off-by: Paolo Bonzini <[email protected]>
2015-12-22KVM: MTRR: observe maxphyaddr from guest CPUID, not hostPaolo Bonzini1-2/+7
Conversion of MTRRs to ranges used the maxphyaddr from the boot CPU. This is wrong, because var_mtrr_range's mask variable then is discontiguous (like FF00FFFF000, where the first run of 0s corresponds to the bits between host and guest maxphyaddr). Instead always set up the masks to be full 64-bit values---we know that the reserved bits at the top are zero, and we can restore them when reading the MSR. This way var_mtrr_range gets a mask that just works. Fixes: a13842dc668b40daef4327294a6d3bdc8bd30276 Cc: [email protected] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561 Signed-off-by: Paolo Bonzini <[email protected]>
2015-12-22KVM: MTRR: fix fixed MTRR segment look upAlexis Dambricourt1-1/+1
This fixes the slow-down of VM running with pci-passthrough, since some MTRR range changed from MTRR_TYPE_WRBACK to MTRR_TYPE_UNCACHABLE. Memory in the 0K-640K range was incorrectly treated as uncacheable. Fixes: f7bfb57b3e89ff89c0da9f93dedab89f68d6ca27 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561 Cc: [email protected] Signed-off-by: Alexis Dambricourt <[email protected]> [Use correct BZ for "Fixes" annotation. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2015-08-05KVM: MTRR: Use default type for non-MTRR-covered gfn before WARN_ONAlex Williamson1-4/+4
The patch was munged on commit to re-order these tests resulting in excessive warnings when trying to do device assignment. Return to original ordering: https://lkml.org/lkml/2015/7/15/769 Fixes: 3e5d2fdceda1 ("KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type") Signed-off-by: Alex Williamson <[email protected]> Reviewed-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-07-23KVM: MTRR: simplify kvm_mtrr_get_guest_memory_typeXiao Guangrong1-9/+10
kvm_mtrr_get_guest_memory_type never returns -1 which is implied in the current code since if @type = -1 (means no MTRR contains the range), iter.partial_map must be true Simplify the code to indicate this fact Signed-off-by: Xiao Guangrong <[email protected]> Tested-by: Alex Williamson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-07-23KVM: MTRR: fix memory type handling if MTRR is completely disabledXiao Guangrong1-1/+20
Currently code uses default memory type if MTRR is fully disabled, fix it by using UC instead. Signed-off-by: Xiao Guangrong <[email protected]> Tested-by: Alex Williamson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: do not map huge page for non-consistent rangeXiao Guangrong1-0/+29
Based on Intel's SDM, mapping huge page which do not have consistent memory cache for each 4k page will cause undefined behavior In order to avoiding this kind of undefined behavior, we force to use 4k pages under this case Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: simplify kvm_mtrr_get_guest_memory_typeXiao Guangrong1-48/+16
mtrr_for_each_mem_type() is ready now, use it to simplify kvm_mtrr_get_guest_memory_type() Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: introduce mtrr_for_each_mem_typeXiao Guangrong1-0/+188
It walks all MTRRs and gets all the memory cache type setting for the specified range also it checks if the range is fully covered by MTRRs Signed-off-by: Xiao Guangrong <[email protected]> [Adjust for range_size->range_shift change. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: introduce fixed_mtrr_addr_* functionsXiao Guangrong1-0/+25
Two functions are introduced: - fixed_mtrr_addr_to_seg() translates the address to the fixed MTRR segment - fixed_mtrr_addr_seg_to_range_index() translates the address to the index of kvm_mtrr.fixed_ranges[] They will be used in the later patch Signed-off-by: Xiao Guangrong <[email protected]> [Adjust for range_size->range_shift change. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: sort variable MTRRsXiao Guangrong1-10/+40
Sort all valid variable MTRRs based on its base address, it will help us to check a range to see if it's fully contained in variable MTRRs Signed-off-by: Xiao Guangrong <[email protected]> [Fix list insertion sort, simplify var_mtrr_range_is_valid to just test the V bit. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: introduce var_mtrr_rangeXiao Guangrong1-6/+17
It gets the range for the specified variable MTRR Signed-off-by: Xiao Guangrong <[email protected]> [Simplify boolean operations. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: introduce fixed_mtrr_segment tableXiao Guangrong1-53/+147
This table summarizes the information of fixed MTRRs and introduce some APIs to abstract its operation which helps us to clean up the code and will be used in later patches Signed-off-by: Xiao Guangrong <[email protected]> [Change range_size to range_shift, in order to avoid udivdi3 errors. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: improve kvm_mtrr_get_guest_memory_typeXiao Guangrong1-45/+49
- kvm_mtrr_get_guest_memory_type() only checks one page in MTRRs so that it's unnecessary to check to see if the range is partially covered in MTRR - optimize the check of overlap memory type and add some comments to explain the precedence Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: do not split 64 bits MSR contentXiao Guangrong1-22/+10
Variable MTRR MSRs are 64 bits which are directly accessed with full length, no reason to split them to two 32 bits Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: clean up mtrr default typeXiao Guangrong1-12/+28
Drop kvm_mtrr->enable, omit the decode/code workload and get rid of all the hard code Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: remove mtrr_state.have_fixedXiao Guangrong1-4/+3
vMTRR does not depend on any host MTRR feature and fixed MTRRs have always been implemented, so drop this field Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: MTRR: handle MSR_MTRRcap in kvm_mtrr_get_msrXiao Guangrong1-0/+12
MSR_MTRRcap is a MTRR msr so move the handler to the common place, also add some comments to make the hard code more readable Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-06-19KVM: x86: move MTRR related code to a separate fileXiao Guangrong1-0/+335
MTRR code locates in x86.c and mmu.c so that move them to a separate file to make the organization more clearer and it will be the place where we fully implement vMTRR Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.