Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp2983523imw; Wed, 6 Jul 2022 15:20:09 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vygAXFA6ek2k5ZAUvVAUtruzD6FZPfs1MVicbFzkgfLr3kJmq8P/GsitkXRkSIFy1+A8Dy X-Received: by 2002:a17:907:2e0d:b0:72a:a16d:27dd with SMTP id ig13-20020a1709072e0d00b0072aa16d27ddmr25251408ejc.344.1657146008760; Wed, 06 Jul 2022 15:20:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657146008; cv=none; d=google.com; s=arc-20160816; b=l/d/hlGcWsgshm6Yw8avQLoeEcr8yVjMSiULbcW5kep5O7TdrXfLoq8j82G0pJABJa 741rBOs8U+5kNIzR6bGPTAzX28zIMIctjrle/a3F0UU3X1uy5u48A2i35mnYV3d5WldK 7E4ASBtFK7k3tnndbe9mZtGnHhaOHvXqRCjNbWJCNEtp++bL9EofFA4E5kP1KE28/B58 mgS66cC4cuplfHnplNxhjetuM8Xyu12g5gU33dr/HqtyBtjXW0xsEgg3sCj2bjgqUEfW dYkJgbd1SY3JxbmL4mhfn9MjOTaKB98INMTaUYatqYxj6AZhgjCy6ZR9UgOG9gQE12AH EbNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=1EMMmqphd91Ju+K/4EV2gpB3SCsQxfnUR4WTRXFnUaw=; b=K30affO0dI5gXBGyyvZkzAojbmVJ0BolXTezCvC7qJzRl47OcpIG9MPsj7XAycoSrx SK7U/NBtfVgahNljNdgL2ry0GmZX5zYXANGgarXdcecYUAtBES9tnm30dd6+1pd2V+Xd DCRw+Ia2T2hiC6+iLHA/wOsV4fH/yqVCaujapPYhyNTWG07wypDjsCD/+SWJmoh/iaCo enL1so0U7z7Y9uv8ercNKCWnA7r6uXcp/iHiFCbo9phAfkmPGPbFUmVGkwQU2rwLO+eA 6Cj2Z54IQMhhX3LCEStXRDg+tyMCuir14tO15rfqAI3U8DdYMehwfj8I3kxIXlJEA5zt EddA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=JUAKZLgf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd21-20020a1709076e1500b006feb8cc7e2asi1105767ejc.503.2022.07.06.15.19.43; Wed, 06 Jul 2022 15:20:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=JUAKZLgf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230424AbiGFWRn (ORCPT + 99 others); Wed, 6 Jul 2022 18:17:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232287AbiGFWRl (ORCPT ); Wed, 6 Jul 2022 18:17:41 -0400 Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2871C2B184 for ; Wed, 6 Jul 2022 15:17:40 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id 73-20020a9d084f000000b00616b04c7656so12780738oty.3 for ; Wed, 06 Jul 2022 15:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1EMMmqphd91Ju+K/4EV2gpB3SCsQxfnUR4WTRXFnUaw=; b=JUAKZLgflnGvGeY8IT6zP5OMaHQ6VMe5txVcGNkWPkN5pW8lnvNe1NeuVhmEOa7le7 +CTn3Yy1P35wIc/RxOoOX7e5EFrgzZ6N/3dFbKln656S4EK1O2pVJcP/23F0Ia8hvY9/ 8+FE7oy1Igk8AS8hxlWEURY23hpln8UL9PdP8Zta9mpwgCTklHMay6n8UeTbSxAu940m 5yZg8qnF5+qmTqyRm8V6NP68KoBw+huVP03/30Tg4RfF9i9oBocSxaSxEu7zdLtWK11K mfp/qiX/28WzZSheMJhBqXiKnpx3AkF9dVh+IEFM93tYahd7YP3+K3ZASvKhzzJXWG9/ I9UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1EMMmqphd91Ju+K/4EV2gpB3SCsQxfnUR4WTRXFnUaw=; b=Uuq8fwwSprt8aWvK+XMk8fyygERrZrM8twP1yrW6I49/99wRHiRkuV1+YhuZYSISnz ocSVJj4pDeLUlkax04DzsjH8feGAT2BfqalaqwubFb/W641yfOrpm3tDkr1fpfv7/TMh avkvLBf2uPQgaEr4dRJejtDLn6bHmQp506yr0EcaFLp41HjnQqGeORdYDOdQ7ef8xewI /43nAHaD9YM1MnS4FPTK5FTaM+sgQagXAnLlZHwlkfI+SAvQR7MY2IjnUkOIUiWaT3M7 fU2EeerA9wi3br/bfb59ATEEy724pqI8i5pnmXbuu3zELkmNEB8gzgUG3keKfyImbmra paVw== X-Gm-Message-State: AJIora+pqdre8uzxG1KceeCaVYWUzqJB6BYHyM/+scIUwecMzXQLgtWg sCUZNgTZF0RYbWzbtDgI73hnxLZnB+oxTWq9EwAzpg== X-Received: by 2002:a05:6830:14:b0:616:dcbd:e53e with SMTP id c20-20020a056830001400b00616dcbde53emr17979803otp.267.1657145859328; Wed, 06 Jul 2022 15:17:39 -0700 (PDT) MIME-Version: 1.0 References: <20220614204730.3359543-1-seanjc@google.com> <20220614204730.3359543-4-seanjc@google.com> In-Reply-To: <20220614204730.3359543-4-seanjc@google.com> From: Jim Mattson Date: Wed, 6 Jul 2022 15:17:28 -0700 Message-ID: Subject: Re: [PATCH v2 03/21] KVM: x86: Don't check for code breakpoints when emulating on exception To: Sean Christopherson Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Oliver Upton , Peter Shier Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 14, 2022 at 1:47 PM Sean Christopherson wrote: > > 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?". IIRC, AMD does not prematurely clobber EFLAGS.RF on an intercepted exception. This is actually a big deal with shadow paging. On Intel, the hypervisor can't fully squash a #PF and restart the guest instruction after filling in the shadow page table entry...not easily, anyway. (OTOH, AMD does prematurely clobber DR6 and DR7 on an intercepted #DB. So, no one should be celebrating!)