- Dec 23, 2022
-
-
Sean Christopherson authored
Set ENABLE_USR_WAIT_PAUSE in KVM's supported VMX MSR configuration if the feature is supported in hardware and enabled in KVM's base, non-nested configuration, i.e. expose ENABLE_USR_WAIT_PAUSE to L1 if it's supported. This fixes a bug where saving/restoring, i.e. migrating, a vCPU will fail if WAITPKG (the associated CPUID feature) is enabled for the vCPU, and obviously allows L1 to enable the feature for L2. KVM already effectively exposes ENABLE_USR_WAIT_PAUSE to L1 by stuffing the allowed-1 control ina vCPU's virtual MSR_IA32_VMX_PROCBASED_CTLS2 when updating secondary controls in response to KVM_SET_CPUID(2), but (a) that depends on flawed code (KVM shouldn't touch VMX MSRs in response to CPUID updates) and (b) runs afoul of vmx_restore_control_msr()'s restriction that the guest value must be a strict subset of the supported host value. Although no past commit explicitly enabled nested support for WAITPKG, doing so is safe and functionally correct from an architectural perspective as no additional KVM support is needed to virtualize TPAUSE, UMONITOR, and UMWAIT for L2 relative to L1, and KVM already forwards VM-Exits to L1 as necessary (commit bf653b78, "KVM: vmx: Introduce handle_unexpected_vmexit and handle WAITPKG vmexit"). Note, KVM always keeps the hosts MSR_IA32_UMWAIT_CONTROL resident in hardware, i.e. always runs both L1 and L2 with the host's power management settings for TPAUSE and UMWAIT. See commit bf09fb6c ("KVM: VMX: Stop context switching MSR_IA32_UMWAIT_CONTROL") for more details. Fixes: e69e72fa ("KVM: x86: Add support for user wait instructions") Cc: stable@vger.kernel.org Reported-by:
Aaron Lewis <aaronlewis@google.com> Reported-by:
Yu Zhang <yu.c.zhang@linux.intel.com> Signed-off-by:
Sean Christopherson <seanjc@google.com> Reviewed-by:
Jim Mattson <jmattson@google.com> Message-Id: <20221213062306.667649-2-seanjc@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Sean Christopherson authored
Explicitly drop the result of kvm_vcpu_write_guest() when writing the "launch state" as part of VMCLEAR emulation, and add a comment to call out that KVM's behavior is architecturally valid. Intel's pseudocode effectively says that VMCLEAR is a nop if the target VMCS address isn't in memory, e.g. if the address points at MMIO. Add a FIXME to call out that suppressing failures on __copy_to_user() is wrong, as memory (a memslot) does exist in that case. Punt the issue to the future as open coding kvm_vcpu_write_guest() just to make sure the guest dies with -EFAULT isn't worth the extra complexity. The flaw will need to be addressed if KVM ever does something intelligent on uaccess failures, e.g. to support post-copy demand paging, but in that case KVM will need a more thorough overhaul, i.e. VMCLEAR shouldn't need to open code a core KVM helper. No functional change intended. Reported-by:
coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1527765 ("Error handling issues") Fixes: 587d7e72 ("kvm: nVMX: VMCLEAR should not cause the vCPU to shut down") Cc: Jim Mattson <jmattson@google.com> Signed-off-by:
-
Sean Christopherson authored
Add a sanity check in kvm_handle_memory_failure() to assert that a valid x86_exception structure is provided if the memory "failure" wants to propagate a fault into the guest. If a memory failure happens during a direct guest physical memory access, e.g. for nested VMX, KVM hardcodes the failure to X86EMUL_IO_NEEDED and doesn't provide an exception pointer (because the exception struct would just be filled with garbage). Signed-off-by:
-
Peng Hao authored
kvm_apic_hw_enabled() only needs to return bool, there is no place to use the return value of MSR_IA32_APICBASE_ENABLE. Signed-off-by:
Peng Hao <flyingpeng@tencent.com> Message-Id: <CAPm50aJ=BLXNWT11+j36Dd6d7nz2JmOBk4u7o_NPQ0N61ODu1g@mail.gmail.com> Signed-off-by:
-
Vitaly Kuznetsov authored
In kvm_hv_flush_tlb(), 'data_offset' and 'consumed_xmm_halves' variables are used in a mutually exclusive way: in 'hc->fast' we count in 'XMM halves' and increase 'data_offset' otherwise. Coverity discovered, that in one case both variables are incremented unconditionally. This doesn't seem to cause any issues as the only user of 'data_offset'/'consumed_xmm_halves' data is kvm_hv_get_tlb_flush_entries() -> kvm_hv_get_hc_data() which also takes into account 'hc->fast' but is still worth fixing. To make things explicit, put 'data_offset' and 'consumed_xmm_halves' to 'struct kvm_hv_hcall' as a union and use at call sites. This allows to remove explicit 'data_offset'/'consumed_xmm_halves' parameters from kvm_hv_get_hc_data()/kvm_get_sparse_vp_set()/kvm_hv_get_tlb_flush_entries() helpers. Note: 'struct kvm_hv_hcall' is allocated on stack in kvm_hv_hypercall() and is not zeroed, consumers are supposed to initialize the appropriate field if needed. Reported-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by:
-
Adamos Ttofari authored
When scanning userspace I/OAPIC entries, intercept EOI for level-triggered IRQs if the current vCPU has a pending and/or in-service IRQ for the vector in its local API, even if the vCPU doesn't match the new entry's destination. This fixes a race between userspace I/OAPIC reconfiguration and IRQ delivery that results in the vector's bit being left set in the remote IRR due to the eventual EOI not being forwarded to the userspace I/OAPIC. Commit 0fc5a36d ("KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race") fixed the in-kernel IOAPIC, but not the userspace IOAPIC configuration, which has a similar race. Fixes: 0fc5a36d ("KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race") Signed-off-by:
Adamos Ttofari <attofari@amazon.de> Reviewed-by:
-
Like Xu authored
The current vPMU can reuse the same pmc->perf_event for the same hardware event via pmc_pause/resume_counter(), but this optimization does not apply to a portion of the TSX events (e.g., "event=0x3c,in_tx=1, in_tx_cp=1"), where event->attr.sample_period is legally zero at creation, thus making the perf call to perf_event_period() meaningless (no need to adjust sample period in this case), and instead causing such reusable perf_events to be repeatedly released and created. Avoid releasing zero sample_period events by checking is_sampling_event() to follow the previously enable/disable optimization. Signed-off-by:
Like Xu <likexu@tencent.com> Message-Id: <20221207071506.15733-2-likexu@tencent.com> Signed-off-by:
-
- Dec 05, 2022
-
-
Ryan Roberts authored
get_user_mapping_size() uses kvm's pgtable library to walk a user space page table created by the kernel, and in doing so, passes metadata that the library needs, including ia_bits, which defines the size of the input address. For the case where the kernel is compiled for 52 VA bits but runs on HW that does not support LVA, it will fall back to 48 VA bits at runtime. Therefore we must use vabits_actual rather than VA_BITS to get the true address size. This is benign in the current code base because the pgtable library only uses it for error checking. Fixes: 6011cf68 ("KVM: arm64: Walk userspace page tables to compute the THP mapping size") Signed-off-by:
Ryan Roberts <ryan.roberts@arm.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221205114031.3972780-1-ryan.roberts@arm.com
-
Marc Zyngier authored
Fix the bogus masking when computing the period of a 64bit counter with 32bit overflow. It really should be treated like a 32bit counter for the purpose of the period. Reported-by:
Ricardo Koller <ricarkol@google.com> Signed-off-by:
-
- Dec 02, 2022
-
-
Jim Mattson authored
CPUID.80000021H:EAX[bit 9] indicates that the SMM_CTL MSR (0xc0010116) is not supported. This defeature can be advertised by KVM_GET_SUPPORTED_CPUID regardless of whether or not the host enumerates it; currently it will be included only if the host enumerates at least leaf 8000001DH, due to a preexisting bug in QEMU that KVM has to work around (commit f751d8ea, "KVM: x86: work around QEMU issue with synthetic CPUID leaves", 2022-04-29). Signed-off-by:
-
Paolo Bonzini authored
Several symbols are not used by vendor modules but still exported. Removing them ensures that new coupling between kvm.ko and kvm-*.ko is noticed and reviewed. Co-developed-by:
Like Xu <like.xu.linux@gmail.com> Signed-off-by:
-
Yuan ZhaoXiong authored
When a VM reboots itself, the reset process will result in an ioctl(KVM_SET_LAPIC, ...) to disable x2APIC mode and set the xAPIC id of the vCPU to its default value, which is the vCPU id. That will be handled in KVM as follows: kvm_vcpu_ioctl_set_lapic kvm_apic_set_state kvm_lapic_set_base => disable X2APIC mode kvm_apic_state_fixup kvm_lapic_xapic_id_updated kvm_xapic_id(apic) != apic->vcpu->vcpu_id kvm_set_apicv_inhibit(APICV_INHIBIT_REASON_APIC_ID_MODIFIED) memcpy(vcpu->arch.apic->regs, s->regs, sizeof(*s)) => update APIC_ID When kvm_apic_set_state invokes kvm_lapic_set_base to disable x2APIC mode, the old 32-bit x2APIC id is still present rather than the 8-bit xAPIC id. kvm_lapic_xapic_id_updated will set the APICV_INHIBIT_REASON_APIC_ID_MODIFIED bit and disable APICv/x2AVIC. Instead, kvm_lapic_xapic_id_updated must be called after APIC_ID is changed. In fact, this fixes another small issue in the code in that potential changes to a vCPU's xAPIC ID need not be tracked for KVM_GET_LAPIC. Fixes: 3743c2f0 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or APIC base") Signed-off-by:Yuan ZhaoXiong <yuanzhaoxiong@baidu.com> Message-Id: <1669984574-32692-1-git-send-email-yuanzhaoxiong@baidu.com> Cc: stable@vger.kernel.org Reported-by:
Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Signed-off-by:
-
Javier Martinez Canillas authored
The documentation says that the ioctl has been deprecated, but it has been actually removed and the remaining references are just left overs. Suggested-by:
Javier Martinez Canillas <javierm@redhat.com> Message-Id: <20221202105011.185147-3-javierm@redhat.com> Signed-off-by:
-
- Dec 01, 2022
-
-
Will Deacon authored
With the new-fangled generation of asm/sysreg-defs.h, some definitions have ended up being duplicated between the two files. Remove these duplicate definitions, and consolidate the naming for GMID_EL1_BS_WIDTH. Signed-off-by:Will Deacon <will@kernel.org>
-
James Morse authored
Convert ID_DFR1_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20221130171637.718182-39-james.morse@arm.com Signed-off-by:
-
James Morse authored
Convert ID_DFR0_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Signed-off-by:
-
James Morse authored
Convert ID_AFR0_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_MMFR5_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert MVFR2_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert MVFR1_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert MVFR0_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_PFR2_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_PFR1_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_PFR0_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Signed-off-by:
-
James Morse authored
Convert ID_ISAR6_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_ISAR5_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_ISAR4_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_ISAR3_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_ISAR2_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_ISAR1_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_ISAR0_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_MMFR4_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_MMFR3_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_MMFR2_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_MMFR1_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
Convert ID_MMFR0_EL1 to be automatically generated as per DDI0487I.a, no functional changes. Reviewed-by:
-
James Morse authored
32bit has multiple values for its id registers, as extra properties were added to the CPUs. Some of these end up having long names, which exceed the fixed 48 character column that the sysreg awk script generates. For example, the ID_MMFR1_EL1.L1Hvd field has an encoding whose natural name would be 'invalidate Iside only'. Using this causes compile errors as the script generates the following: #define ID_MMFR1_EL1_L1Hvd_INVALIDATE_ISIDE_ONLYUL(0b0001) Add a few extra characters. Reviewed-by:
-
James Morse authored
To convert the 32bit id registers to use the sysreg generation, they must first have a regular pattern, to match the symbols the script generates. Ensure symbols for the MVFR2_EL1 register use lower-case for feature names where the arm-arm does the same. No functional change. Signed-off-by:
-
James Morse authored
To convert the 32bit id registers to use the sysreg generation, they must first have a regular pattern, to match the symbols the script generates. Ensure symbols for the MVFR1_EL1 register use lower-case for feature names where the arm-arm does the same. No functional change. Signed-off-by:
-
James Morse authored
To convert the 32bit id registers to use the sysreg generation, they must first have a regular pattern, to match the symbols the script generates. Ensure symbols for the MVFR0_EL1 register use lower-case for feature names where the arm-arm does the same. No functional change. Signed-off-by:
-
