From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC0EFC433EF for ; Fri, 15 Jul 2022 20:42:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231626AbiGOUmx (ORCPT ); Fri, 15 Jul 2022 16:42:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230413AbiGOUml (ORCPT ); Fri, 15 Jul 2022 16:42:41 -0400 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04B8E87C3E for ; Fri, 15 Jul 2022 13:42:39 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-31cbcba2f28so47759647b3.19 for ; Fri, 15 Jul 2022 13:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=XaWS8LbhbBC14KHRu/UMZ0VrY5IYn1B7OmHtIsROozk=; b=FxXXiG7IAizzt0hgccKAXP+W3ljcErsJLZbJeNfT7M2oIx33QM508seYqWjRWt3Gvz I1fLkEyrAvAH4AL4RuCjYVswSaIEPNNRB0qnLVHCrfvSTKhs2wNTLjpUxVlx3ILUIvVw hcGnO72MJ+W84VkhzA2tDsy9YpdBHAG8qnvdMSQ0cliOol5SQzxDLnPglfHyt8MItuZQ 38mxtL+96Argz1UQmzN4ZPg9BmOQLJfKHatFRyGbU9SLw4H/3oyM3sSrx0UpbTckkMj6 SUN6mq2PNlaB+kNc9fdsIKu5VOpPyFA4VbyiyDg/20KV8PvVjqYH35D7Qebor5hsci4f 7FdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=XaWS8LbhbBC14KHRu/UMZ0VrY5IYn1B7OmHtIsROozk=; b=sv5E0726/Nh/NHkIrBiZF8dDUG3S0lC1j69oWtYU0Os831xDk074sBv13EYSGsgrZj objdHJJaX6UELqA12E071H5+I1yNfO4OVKAlxSqDTejtYBHLC3naiwKs3zgskbxYM81g l7fyc4V0PpZ3U5gZLnbyoA6H5ZDMkdOCFPo2iUh7bukwzLWicmjdLT4ykz2wyLvTUHeV qZYpetabbj/WhfAgCnqcPbUi0DTvcoEJhEU4mFEkV04hqR8VRfmiGdJbtmofH152D8tJ 2HPSipx0gVQM1/A9I+hYL6fqto8zLi8B0viPwcXg1f1Mh9SfR41RstHkHSXZTfB3yO8l aVqw== X-Gm-Message-State: AJIora/5isKqVbT9WdtNZo+7r5UiZQh4WxAzrhwdcn0PAM8wq2ze0HRA 7Az7VleK/GfUli14YPPkaPOtAyF5OdI= X-Google-Smtp-Source: AGRyM1usU0pP86LIERbZu4Kai+tEgErFUJB47c2GKFB2+e50nsaw7Up7PfX2doLx1/n0IaB6CFPcH/l+ehk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:88a:0:b0:31c:51cd:9e09 with SMTP id 132-20020a81088a000000b0031c51cd9e09mr18049167ywi.374.1657917759022; Fri, 15 Jul 2022 13:42:39 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 15 Jul 2022 20:42:05 +0000 In-Reply-To: <20220715204226.3655170-1-seanjc@google.com> Message-Id: <20220715204226.3655170-4-seanjc@google.com> Mime-Version: 1.0 References: <20220715204226.3655170-1-seanjc@google.com> X-Mailer: git-send-email 2.37.0.170.g444d1eabd0-goog Subject: [PATCH v2 03/24] KVM: x86: Don't check for code breakpoints when emulating on exception From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson , Maxim Levitsky , Oliver Upton , Peter Shier Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Don't check for code breakpoints during instruction emulation if the emulation was triggered by exception interception. Code breakpoints are the highest priority fault-like exception, and KVM only emulates on exceptions that are fault-like. Thus, if hardware signaled a different exception, then the vCPU is already passed the stage of checking for hardware breakpoints. This is likely a glorified nop in terms of functionality, and is more for clarification and is technically an optimization. Intel's SDM explicitly states vmcs.GUEST_RFLAGS.RF on exception interception is the same as the value that would have been saved on the stack had the exception not been intercepted, i.e. will be '1' due to all fault-like exceptions setting RF to '1'. AMD says "guest state saved ... is the processor state as of the moment the intercept triggers", but that begs the question, "when does the intercept trigger?". Signed-off-by: Sean Christopherson Reviewed-by: Maxim Levitsky --- arch/x86/kvm/x86.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index f389691d8c04..4efdb61e60ba 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -8517,8 +8517,24 @@ int kvm_skip_emulated_instruction(struct kvm_vcpu *vcpu) } EXPORT_SYMBOL_GPL(kvm_skip_emulated_instruction); -static bool kvm_vcpu_check_code_breakpoint(struct kvm_vcpu *vcpu, int *r) +static bool kvm_vcpu_check_code_breakpoint(struct kvm_vcpu *vcpu, + int emulation_type, int *r) { + WARN_ON_ONCE(emulation_type & EMULTYPE_NO_DECODE); + + /* + * Do not check for code breakpoints if hardware has already done the + * checks, as inferred from the emulation type. On NO_DECODE and SKIP, + * the instruction has passed all exception checks, and all intercepted + * exceptions that trigger emulation have lower priority than code + * breakpoints, i.e. the fact that the intercepted exception occurred + * means any code breakpoints have already been serviced. + */ + if (emulation_type & (EMULTYPE_NO_DECODE | EMULTYPE_SKIP | + EMULTYPE_TRAP_UD | EMULTYPE_TRAP_UD_FORCED | + EMULTYPE_VMWARE_GP | EMULTYPE_PF)) + return false; + if (unlikely(vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) && (vcpu->arch.guest_debug_dr7 & DR7_BP_EN_MASK)) { struct kvm_run *kvm_run = vcpu->run; @@ -8640,8 +8656,7 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, * are fault-like and are higher priority than any faults on * the code fetch itself. */ - if (!(emulation_type & EMULTYPE_SKIP) && - kvm_vcpu_check_code_breakpoint(vcpu, &r)) + if (kvm_vcpu_check_code_breakpoint(vcpu, emulation_type, &r)) return r; r = x86_decode_emulated_instruction(vcpu, emulation_type, -- 2.37.0.170.g444d1eabd0-goog