- 14 Jul, 2022 22 commits
-
-
Sean Christopherson authored
Remove the MMU role test, which was made obsolete by KVM commit feb627e8 ("KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN"). The ongoing costs of keeping the test updated far outweigh any benefits, e.g. the test _might_ be useful as an example or for documentation purposes, but otherwise the test is dead weight. Signed-off-by:
Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/r/20220614200707.3315957-14-seanjc@google.com
-
Sean Christopherson authored
Use kvm_cpu_has() in the CR4/CPUID sync test instead of open coding equivalent functionality using kvm_get_supported_cpuid_entry(). No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Use kvm_cpu_has() in the AMX test instead of open coding equivalent functionality using kvm_get_supported_cpuid_entry() and kvm_get_supported_cpuid_index(). No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Check for _both_ XTILE data and cfg support in the AMX test instead of checking for _either_ feature. Practically speaking, no sane CPU or vCPU will support one but not the other, but the effective "or" behavior is subtle and technically incorrect. Signed-off-by:
-
Sean Christopherson authored
Use kvm_cpu_has() in the XSS MSR test instead of open coding equivalent functionality using kvm_get_supported_cpuid_index(). No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Drop a redundant vcpu_set_cpuid() from the PMU test. The vCPU's CPUID is set to KVM's supported CPUID by vm_create_with_one_vcpu(), which was also true back when the helper was named vm_create_default(). Signed-off-by:
-
Sean Christopherson authored
Use kvm_cpu_has() in the PMU test to query PDCM support instead of open coding equivalent functionality using kvm_get_supported_cpuid_index(). No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Use kvm_cpu_has() to check for nested VMX support, and drop the helpers now that their functionality is trivial to implement. No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Use kvm_cpu_has() to check for nested SVM support, and drop the helpers now that their functionality is trivial to implement. No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Use kvm_cpu_has() in the SEV migration test instead of open coding equivalent functionality using kvm_get_supported_cpuid_entry(). No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Add X86_FEATURE_* magic in the style of KVM-Unit-Tests' implementation, where the CPUID function, index, output register, and output bit position are embedded in the macro value. Add kvm_cpu_has() to query KVM's supported CPUID and use it set_sregs_test, which is the most prolific user of manual feature querying. Opportunstically rename calc_cr4_feature_bits() to calc_supported_cr4_feature_bits() to better capture how the CR4 bits are chosen. Link: https://lore.kernel.org/all/20210422005626.564163-1-ricarkol@google.comSuggested-by:
Paolo Bonzini <pbonzini@redhat.com> Suggested-by:
Jim Mattson <jmattson@google.com> Signed-off-by:
-
Sean Christopherson authored
Rename X86_FEATURE_* macros to CPUID_* in various tests to free up the X86_FEATURE_* names for KVM-Unit-Tests style CPUID automagic where the function, leaf, register, and bit for the feature is embedded in its macro value. No functional change intended. Signed-off-by:
-
Sean Christopherson authored
On x86-64, set KVM's supported CPUID as the vCPU's CPUID when recreating a VM+vCPU to deduplicate code for state save/restore tests, and to provide symmetry of sorts with respect to vm_create_with_one_vcpu(). The extra KVM_SET_CPUID2 call is wasteful for Hyper-V, but ultimately is nothing more than an expensive nop, and overriding the vCPU's CPUID with the Hyper-V CPUID information is the only known scenario where a state save/restore test wouldn't need/want the default CPUID. Opportunistically use __weak for the default vm_compute_max_gfn(), it's provided by tools' compiler.h. Signed-off-by:
-
Colton Lewis authored
Fix filename reporting in guest asserts by ensuring the GUEST_ASSERT macro records __FILE__ and substituting REPORT_GUEST_ASSERT for many repetitive calls to TEST_FAIL. Previously filename was reported by using __FILE__ directly in the selftest, wrongly assuming it would always be the same as where the assertion failed. Signed-off-by:
Colton Lewis <coltonlewis@google.com> Reported-by:
Ricardo Koller <ricarkol@google.com> Fixes: 4e18bccc Link: https://lore.kernel.org/r/20220615193116.806312-5-coltonlewis@google.com [sean: convert more TEST_FAIL => REPORT_GUEST_ASSERT instances] Signed-off-by:
-
Colton Lewis authored
Write REPORT_GUEST_ASSERT macros to pair with GUEST_ASSERT to abstract and make consistent all guest assertion reporting. Every report includes an explanatory string, a filename, and a line number. Signed-off-by:
Andrew Jones <drjones@redhat.com> Link: https://lore.kernel.org/r/20220615193116.806312-4-coltonlewis@google.comSigned-off-by:
-
Colton Lewis authored
Increase UCALL_MAX_ARGS to 7 to allow GUEST_ASSERT_4 to pass 3 builtin ucall arguments specified in guest_assert_builtin_args plus 4 user-specified arguments. Signed-off-by:
-
Colton Lewis authored
Enumerate GUEST_ASSERT arguments to avoid magic indices to ucall.args. Signed-off-by:
-
Sean Christopherson authored
Change a WARN_ON() to separate WARN_ON_ONCE() if KVM has an outstanding PIO or MMIO request without an associated callback, i.e. if KVM queued a userspace I/O exit but didn't actually exit to userspace before moving on to something else. Warning on every KVM_RUN risks spamming the kernel if KVM gets into a bad state. Opportunistically split the WARNs so that it's easier to triage failures when a WARN fires. Deliberately do not use KVM_BUG_ON(), i.e. don't kill the VM. While the WARN is all but guaranteed to fire if and only if there's a KVM bug, a dangling I/O request does not present a danger to KVM (that flag is truly truly consumed only in a single emulator path), and any such bug is unlikely to be fatal to the VM (KVM essentially failed to do something it shouldn't have tried to do in the first place). In other words, note the bug, but let the VM keep running. Signed-off-by:
Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20220711232750.1092012-4-seanjc@google.comSigned-off-by:
-
Sean Christopherson authored
When injecting a #GP on LLDT/LTR due to a non-canonical LDT/TSS base, set the error code to the selector. Intel SDM's says nothing about the #GP, but AMD's APM explicitly states that both LLDT and LTR set the error code to the selector, not zero. Note, a non-canonical memory operand on LLDT/LTR does generate a #GP(0), but the KVM code in question is specific to the base from the descriptor. Fixes: e37a75a1 ("KVM: x86: Emulator ignores LDTR/TR extended base on LLDT/LTR") Cc: stable@vger.kernel.org Signed-off-by:
-
Sean Christopherson authored
Wait to mark the TSS as busy during LTR emulation until after all fault checks for the LTR have passed. Specifically, don't mark the TSS busy if the new TSS base is non-canonical. Opportunistically drop the one-off !seg_desc.PRESENT check for TR as the only reason for the early check was to avoid marking a !PRESENT TSS as busy, i.e. the common !PRESENT is now done before setting the busy bit. Fixes: e37a75a1 ("KVM: x86: Emulator ignores LDTR/TR extended base on LLDT/LTR") Reported-by: syzbot+760a73552f47a8cd0fd9@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Hou Wenlong <houwenlong.hwl@antgroup.com> Signed-off-by:
-
Sean Christopherson authored
Add a "UD" clause to KVM_X86_QUIRK_MWAIT_NEVER_FAULTS to make it clear that the quirk only controls the #UD behavior of MONITOR/MWAIT. KVM doesn't currently enforce fault checks when MONITOR/MWAIT are supported, but that could change in the future. SVM also has a virtualization hole in that it checks all faults before intercepts, and so "never faults" is already a lie when running on SVM. Fixes: bfbcc81b ("KVM: x86: Add a quirk for KVM's "MONITOR/MWAIT are NOPs!" behavior") Signed-off-by:
-
Vitaly Kuznetsov authored
Do not use GCC's "A" constraint to load EAX:EDX in wrmsr_safe(). Per GCC's documenation on x86-specific constraints, "A" will not actually load a 64-bit value into EAX:EDX on x86-64. The a and d registers. This class is used for instructions that return double word results in the ax:dx register pair. Single word values will be allocated either in ax or dx. For example on i386 the following implements rdtsc: unsigned long long rdtsc (void) { unsigned long long tick; __asm__ __volatile__("rdtsc":"=A"(tick)); return tick; } This is not correct on x86-64 as it would allocate tick in either ax or dx. You have to use the following variant instead: unsigned long long rdtsc (void) { unsigned int tickl, tickh; __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); return ((unsigned long long)tickh << 32)|tickl; } Because a u64 fits in a single 64-bit register, using "A" for selftests, which are 64-bit only, results in GCC loading the value into either RAX or RDX instead of splitting it across EAX:EDX. E.g.: kvm_exit: reason MSR_WRITE rip 0x402919 info 0 0 kvm_msr: msr_write 40000118 = 0x60000000001 (#GP) ... With "A": 48 8b 43 08 mov 0x8(%rbx),%rax 49 b9 ba da ca ba 0a movabs $0xabacadaba,%r9 00 00 00 4c 8d 15 07 00 00 00 lea 0x7(%rip),%r10 # 402f44 <guest_msr+0x34> 4c 8d 1d 06 00 00 00 lea 0x6(%rip),%r11 # 402f4a <guest_msr+0x3a> 0f 30 wrmsr With "a"/"d": 48 8b 53 08 mov 0x8(%rbx),%rdx 89 d0 mov %edx,%eax 48 c1 ea 20 shr $0x20,%rdx 49 b9 ba da ca ba 0a movabs $0xabacadaba,%r9 00 00 00 4c 8d 15 07 00 00 00 lea 0x7(%rip),%r10 # 402fc3 <guest_msr+0xb3> 4c 8d 1d 06 00 00 00 lea 0x6(%rip),%r11 # 402fc9 <guest_msr+0xb9> 0f 30 wrmsr Fixes: 3b23054c ("KVM: selftests: Add x86-64 support for exception fixup") Signed-off-by:Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints [sean: use "& -1u", provide GCC blurb and link to documentation] Signed-off-by:
-
- 12 Jul, 2022 5 commits
-
-
Sean Christopherson authored
Provide valid inputs for RAX, RCX, and RDX when testing whether or not KVM injects a #UD on MONITOR/MWAIT. SVM has a virtualization hole and checks for _all_ faults before checking for intercepts, e.g. MONITOR with an unsupported RCX will #GP before KVM gets a chance to intercept and emulate. Fixes: 2325d4dd ("KVM: selftests: Add MONITOR/MWAIT quirk test") Signed-off-by:
-
Sean Christopherson authored
Fix a copy+paste error in monitor_mwait_test by switching one of the two "monitor" instructions to an "mwait". The intent of the test is very much to verify the quirk handles both MONITOR and MWAIT. Fixes: 2325d4dd ("KVM: selftests: Add MONITOR/MWAIT quirk test") Reported-by:
Yuan Yao <yuan.yao@linux.intel.com> Signed-off-by:
-
Sean Christopherson authored
Read vcpu->vcpu_idx directly instead of bouncing through the one-line wrapper, kvm_vcpu_get_idx(), and drop the wrapper. The wrapper is a remnant of the original implementation and serves no purpose; remove it (again) before it gains more users. kvm_vcpu_get_idx() was removed in the not-too-distant past by commit 4eeef242 ("KVM: x86: Query vcpu->vcpu_idx directly and drop its accessor"), but was unintentionally re-introduced by commit a54d8066 ("KVM: Keep memslots in tree-based structures instead of array-based ones"), likely due to a rebase goof. The wrapper then managed to gain users in KVM's Xen code. No functional change intended. Signed-off-by:
-
Hou Wenlong authored
The result of gva_to_gpa() is physical address not virtual address, it is odd that UNMAPPED_GVA macro is used as the result for physical address. Replace UNMAPPED_GVA with INVALID_GPA and drop UNMAPPED_GVA macro. No functional change intended. Signed-off-by:
Hou Wenlong <houwenlong.hwl@antgroup.com> Reviewed-by:
-
Vitaly Kuznetsov authored
Windows 10/11 guests with Hyper-V role (WSL2) enabled are observed to hang upon boot or shortly after when a non-default TSC frequency was set for L1. The issue is observed on a host where TSC scaling is supported. The problem appears to be that Windows doesn't use TSC scaling for its guests, even when the feature is advertised, and KVM filters SECONDARY_EXEC_TSC_SCALING out when creating L2 controls from L1's VMCS. This leads to L2 running with the default frequency (matching host's) while L1 is running with an altered one. Keep SECONDARY_EXEC_TSC_SCALING in secondary exec controls for L2 when it was set for L1. TSC_MULTIPLIER is already correctly computed and written by prepare_vmcs02(). Signed-off-by:
-
- 08 Jul, 2022 7 commits
-
-
Vitaly Kuznetsov authored
'vector' and 'trig_mode' fields of 'struct kvm_lapic_irq' are left uninitialized in kvm_pv_kick_cpu_op(). While these fields are normally not needed for APIC_DM_REMRD, they're still referenced by __apic_accept_irq() for trace_kvm_apic_accept_irq(). Fully initialize the structure to avoid consuming random stack memory. Fixes: a183b638 ("KVM: x86: make apic_accept_irq tracepoint more generic") Reported-by: syzbot+d6caa905917d353f0d07@syzkaller.appspotmail.com Signed-off-by:
-
Sean Christopherson authored
Add a helper to update KVM's in-kernel local APIC in response to MCG_CAP being changed by userspace to fix multiple bugs. First and foremost, KVM needs to check that there's an in-kernel APIC prior to dereferencing vcpu->arch.apic. Beyond that, any "new" LVT entries need to be masked, and the APIC version register needs to be updated as it reports out the number of LVT entries. Fixes: 4b903561 ("KVM: x86: Add Corrected Machine Check Interrupt (CMCI) emulation to lapic.") Reported-by: syzbot+8cdad6430c24f396f158@syzkaller.appspotmail.com Cc: Siddh Raman Pant <code@siddh.me> Cc: Jue Wang <juew@google.com> Signed-off-by:
-
Sean Christopherson authored
Initialize the number of LVT entries during APIC creation, else the field will be incorrectly left '0' if userspace never invokes KVM_X86_SETUP_MCE. Add and use a helper to calculate the number of entries even though MCG_CMCI_P is not set by default in vcpu->arch.mcg_cap. Relying on that to always be true is unnecessarily risky, and subtle/confusing as well. Fixes: 4b903561 ("KVM: x86: Add Corrected Machine Check Interrupt (CMCI) emulation to lapic.") Reported-by:
Xiaoyao Li <xiaoyao.li@intel.com> Cc: Jue Wang <juew@google.com> Signed-off-by:
-
Sean Christopherson authored
Merge a bug fix and cleanups for {g,s}et_msr_mce() using a base that predates commit 281b5278 ("KVM: x86: Add emulation for MSR_IA32_MCx_CTL2 MSRs."), which was written with the intention that it be applied _after_ the bug fix and cleanups. The bug fix in particular needs to be sent to stable trees; give them a stable hash to use. -
Sean Christopherson authored
Add helpers to identify CTL (control) and STATUS MCi MSR types instead of open coding the checks using the offset. Using the offset is perfectly safe, but unintuitive, as understanding what the code does requires knowing that the offset calcuation will not affect the lower three bits. Opportunistically comment the STATUS logic to save readers a trip to Intel's SDM or AMD's APM to understand the "data != 0" check. No functional change intended. Signed-off-by:
-
Sean Christopherson authored
Use an explicit case statement to grab the full range of MCx bank MSRs in {g,s}et_msr_mce(), and manually check only the "end" (the number of banks configured by userspace may be less than the max). The "default" trick works, but is a bit odd now, and will be quite odd if/when support for accessing MCx_CTL2 MSRs is added, which has near identical logic. Hoist "offset" to function scope so as to avoid curly braces for the case statement, and because MCx_CTL2 support will need the same variables. Opportunstically clean up the comment about allowing bit 10 to be cleared from bank 4. No functional change intended. Cc: Jue Wang <juew@google.com> Signed-off-by: -
Sean Christopherson authored
Return '1', not '-1', when handling an illegal WRMSR to a MCi_CTL or MCi_STATUS MSR. The behavior of "all zeros' or "all ones" for CTL MSRs is architectural, as is the "only zeros" behavior for STATUS MSRs. I.e. the intent is to inject a #GP, not exit to userspace due to an unhandled emulation case. Returning '-1' gets interpreted as -EPERM up the stack and effecitvely kills the guest. Fixes: 890ca9ae ("KVM: Add MCE support") Fixes: 9ffd986c ("KVM: X86: #GP when guest attempts to write MCi_STATUS register w/o 0") Cc: stable@vger.kernel.org Signed-off-by:
-
- 25 Jun, 2022 2 commits
-
-
Sean Christopherson authored
Buffer split_desc_cache, the cache used to allcoate rmap list entries, only by the default cache capacity (currently 40), not by doubling the minimum (513). Aliasing L2 GPAs to L1 GPAs is uncommon, thus eager page splitting is unlikely to need 500+ entries. And because each object is a non-trivial 128 bytes (see struct pte_list_desc), those extra ~500 entries means KVM is in all likelihood wasting ~64kb of memory per VM. Link: https://lore.kernel.org/all/YrTDcrsn0%2F+alpzf@google.com Cc: David Matlack <dmatlack@google.com> Signed-off-by:
-
Sean Christopherson authored
Use an "unsigned int" for @access parameters instead of a "u32", mostly to be consistent throughout KVM, but also because "u32" is misleading. @access can actually squeeze into a u8, i.e. doesn't need 32 bits, but is as an "unsigned int" because sp->role.access is an unsigned int. No functional change intended. Link: https://lore.kernel.org/all/YqyZxEfxXLsHGoZ%2F@google.com Cc: David Matlack <dmatlack@google.com> Signed-off-by:
-
- 24 Jun, 2022 4 commits
-
-
Paolo Bonzini authored
complete_emulator_pio_in() only has to be called by complete_sev_es_emulated_ins() now; therefore, all that the function does now is adjust sev_pio_count and sev_pio_data. Which is the same for both IN and OUT. No functional change intended. Signed-off-by: -
Paolo Bonzini authored
Now all callers except emulator_pio_in_emulated are using __emulator_pio_in/complete_emulator_pio_in explicitly. Move the "either copy the result or attempt PIO" logic in emulator_pio_in_emulated, and rename __emulator_pio_in to just emulator_pio_in. Signed-off-by: -
Paolo Bonzini authored
Use __emulator_pio_in() directly for fast PIO instead of bouncing through emulator_pio_in() now that __emulator_pio_in() fills "val" when handling in-kernel PIO. vcpu->arch.pio.count is guaranteed to be '0', so this a pure nop. emulator_pio_in_emulated is now the last caller of emulator_pio_in. No functional change intended. Signed-off-by: -
Paolo Bonzini authored
Make emulator_pio_in_out operate directly on the provided buffer as long as PIO is handled inside KVM. For input operations, this means that, in the case of in-kernel PIO, __emulator_pio_in() does not have to be always followed by complete_emulator_pio_in(). This affects emulator_pio_in() and kvm_sev_es_ins(); for the latter, that is why the call moves from advance_sev_es_emulated_ins() to complete_sev_es_emulated_ins(). For output, it means that vcpu->pio.count is never set unnecessarily and there is no need to clear it; but also vcpu->pio.size must not be used in kvm_sev_es_outs(), because it will not be updated for in-kernel OUT. Signed-off-by:
-
