Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp467952pxu; Tue, 5 Jan 2021 16:52:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJy/ItTRoZOJi4RmQ0PjkuaopzPxpXGU8opFoThh30i1koZo1CbX7rkQVJTdlB3GeIQdPJHq X-Received: by 2002:a17:906:3781:: with SMTP id n1mr1327704ejc.296.1609894332770; Tue, 05 Jan 2021 16:52:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609894332; cv=none; d=google.com; s=arc-20160816; b=KwsNa7nRWoVJjQ5/2UJN++WAn97DDBVAW3a/CEVqjefUyvp/Il3OMO4Nqk58S7GEtX sU535Cdwrvz8QBTWbUadBVeT61M7njyArZpBcKHbaJl8V02ERJgbrYG+mOgtpJu2ddpW P/+BcJvs0P5Xx0L1Jk8ypKhcFEZD3JEgs9KcRL8knblgZzmImWDHE66LVoIAsepEiJ1T XcB4bDHEyN0S+Y84og5A6JUqZ2T32CgSry3UWrqqXhOmL9akY667R9WxTvRPn/hjZMyv D96yLF0evwZ5KQg9FrIyiNasBBZac3rkJlYZ8YHqz6qXDZ1E0/s1hTfsb04s3VF1rKnR eRxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=kfZHZyAWKT0gu1CtPbXfDi7dkaM3yoFhEPhGiiQ+Kio=; b=W5VpPMBZHPJGAwXgU2i6L/ESJDPwDo6ZW3RIBo8fJBZ1gCjDU/JkCNKNt/O2daOdj5 iH3Yam5CIYx2fzCASCTqP46SXdAepEDPW5xI443qY9OTpqOERukEDMj+wOUja8oi/oaQ WxyWCMshPfZKOOfqzMsT/5RaicqTzzeNZKdFN+fNVDwmzFsuL+tV4nA5tUbYGnOvsl40 1oqV/ZBynrgodXvO5mqOAStETWx+CdmxK+rJ6fEmSGDNvplbSzAa8Etq12EYkPlIvS3m uTgJMb0Q31ddhRjNB7Jb2Fm1obToZbW8MjAu1dpJUMLWwqKxtEUTt1BpQvhRpV5g25TA bxog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mznuT4pm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jg16si314725ejc.580.2021.01.05.16.51.49; Tue, 05 Jan 2021 16:52:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mznuT4pm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1727288AbhAFArv (ORCPT + 99 others); Tue, 5 Jan 2021 19:47:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726097AbhAFArv (ORCPT ); Tue, 5 Jan 2021 19:47:51 -0500 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DA62C061793 for ; Tue, 5 Jan 2021 16:47:11 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id t22so741544pfl.3 for ; Tue, 05 Jan 2021 16:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kfZHZyAWKT0gu1CtPbXfDi7dkaM3yoFhEPhGiiQ+Kio=; b=mznuT4pmE2K/KBt/x1qYYASeoW2mxiPhdL9Sbt/9EFV6uHc00DGWuRrJ6CDOKiDNPu 3Upf+SBQDOXEjaikajh/x9WEmOrPNw9tnGdMIeZayGxdsD4qS54GvoAM+jAYRk79g2+h TlpBA0N4VR6/UCBCV4gb4UT8UQWnMETvvHYxP+bDAfocQz4oyR8OQ8BuHtHiIAHFBp8I obTORNwqYBEYb6xse0xjjf2uod7csj+3joSolWkamlPLuduLvYCIgngG/Ro3XvYzXjkm 46qOfVcMb1IOK1aBxqOG52EgucJC+mECAmeTyFsfITUk8Ehk+ZCDzDOhdKBLyMYw7KgL fwxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kfZHZyAWKT0gu1CtPbXfDi7dkaM3yoFhEPhGiiQ+Kio=; b=BarCVrMMS9CqSgU38/0i1cpCmxBNekNUeIMSzHXFZ+euYEvowsEvbFwof83fga0+ac sI5Korkz2pX58fm0x1el26DvDBM0A5taIMJyZ0P8dL84+F+OW0eklXtds3YZuKG32m7B YSUTEzB6nrKthb4Bwz4sTMxct/J9M8483eFyZgIcGNXCDEyl2HGjplIudIpL3V2UtG76 AXFrNZ9ktX1FBXEi278CZi333J514+iIrh52Q8w2CD3r3zu19c7kGdbAu/6Ak2XbSTUR GvF+xkEb44TOYGSqDBc5dgwoPm1pSjlE4b/bs8PlVh63b5XuYcI+8M/Gpvafy5tV4TXa zaRQ== X-Gm-Message-State: AOAM531YaMF1P2nPyisO9XDBjrO0o9ZWpf49v1TMkpGI90NUsWGY3rc2 lNh3Xna7j3jd8m69KWHGc0L8wA== X-Received: by 2002:a63:591f:: with SMTP id n31mr1748019pgb.244.1609894030333; Tue, 05 Jan 2021 16:47:10 -0800 (PST) Received: from google.com ([2620:15c:f:10:1ea0:b8ff:fe73:50f5]) by smtp.gmail.com with ESMTPSA id a12sm368788pgq.5.2021.01.05.16.47.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Jan 2021 16:47:09 -0800 (PST) Date: Tue, 5 Jan 2021 16:47:03 -0800 From: Sean Christopherson To: Nitesh Narayan Lal Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, w90p710@gmail.com, pbonzini@redhat.com, vkuznets@redhat.com, Thomas Gleixner Subject: Re: [PATCH] Revert "KVM: x86: Unconditionally enable irqs in guest context" Message-ID: References: <20210105192844.296277-1-nitesh@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210105192844.296277-1-nitesh@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +tglx On Tue, Jan 05, 2021, Nitesh Narayan Lal wrote: > This reverts commit d7a08882a0a4b4e176691331ee3f492996579534. > > After the introduction of the patch: > > 87fa7f3e9: x86/kvm: Move context tracking where it belongs > > since we have moved guest_exit_irqoff closer to the VM-Exit, explicit > enabling of irqs to process pending interrupts should not be required > within vcpu_enter_guest anymore. Ugh, except that commit completely broke tick-based accounting, on both Intel and AMD. With guest_exit_irqoff() being called immediately after VM-Exit, any tick that happens after IRQs are disabled will be accounted to the host. E.g. on Intel, even an IRQ VM-Exit that has already been acked by the CPU isn't processed until kvm_x86_ops.handle_exit_irqoff(), well after PF_VCPU has been cleared. CONFIG_VIRT_CPU_ACCOUNTING_GEN=y should still work (I didn't bother to verify). Thomas, any clever ideas? Handling IRQs in {vmx,svm}_vcpu_enter_exit() isn't an option as KVM hasn't restored enough state to handle an IRQ, e.g. PKRU and XCR0 are still guest values. Is it too heinous to fudge PF_VCPU across KVM's "pending" IRQ handling? E.g. this god-awful hack fixes the accounting: diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 836912b42030..5a777fd35b4b 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9028,6 +9028,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) vcpu->mode = OUTSIDE_GUEST_MODE; smp_wmb(); + current->flags |= PF_VCPU; kvm_x86_ops.handle_exit_irqoff(vcpu); /* @@ -9042,6 +9043,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) ++vcpu->stat.exits; local_irq_disable(); kvm_after_interrupt(vcpu); + current->flags &= ~PF_VCPU; if (lapic_in_kernel(vcpu)) { s64 delta = vcpu->arch.apic->lapic_timer.advance_expire_delta; > Conflicts: > arch/x86/kvm/svm.c > > Signed-off-by: Nitesh Narayan Lal > --- > arch/x86/kvm/svm/svm.c | 9 +++++++++ > arch/x86/kvm/x86.c | 11 ----------- > 2 files changed, 9 insertions(+), 11 deletions(-) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index cce0143a6f80..c9b2fbb32484 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -4187,6 +4187,15 @@ static int svm_check_intercept(struct kvm_vcpu *vcpu, > > static void svm_handle_exit_irqoff(struct kvm_vcpu *vcpu) > { > + kvm_before_interrupt(vcpu); > + local_irq_enable(); > + /* > + * We must have an instruction with interrupts enabled, so > + * the timer interrupt isn't delayed by the interrupt shadow. > + */ > + asm("nop"); > + local_irq_disable(); > + kvm_after_interrupt(vcpu); > } > > static void svm_sched_in(struct kvm_vcpu *vcpu, int cpu) > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 3f7c1fc7a3ce..3e17c9ffcad8 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -9023,18 +9023,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > > kvm_x86_ops.handle_exit_irqoff(vcpu); > > - /* > - * Consume any pending interrupts, including the possible source of > - * VM-Exit on SVM and any ticks that occur between VM-Exit and now. > - * An instruction is required after local_irq_enable() to fully unblock > - * interrupts on processors that implement an interrupt shadow, the > - * stat.exits increment will do nicely. > - */ > - kvm_before_interrupt(vcpu); > - local_irq_enable(); > ++vcpu->stat.exits; > - local_irq_disable(); > - kvm_after_interrupt(vcpu); > > if (lapic_in_kernel(vcpu)) { > s64 delta = vcpu->arch.apic->lapic_timer.advance_expire_delta; > -- > 2.27.0 >