From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::241; helo=mail-it0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F265122489CB1 for ; Fri, 16 Mar 2018 04:21:57 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id d13-v6so1718966itf.0 for ; Fri, 16 Mar 2018 04:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gT/HWxyHwkkstNangg3ETk16uCp3ZxQW6V2aeBuClxo=; b=H2Lea8lRdzZWLZv/oBqt36xstNPRZjt3owQ5Nk3Lc71sjc172TzBAFwtYY4m4TNHm7 dQOKnAvtJ6Npnn6pn122gmk9cav+NtxcT2QjuLJEddlF8HyHidqBNYMPAfAbrJAvNnp6 d9QaT2KZn8CnvfZfvlylHTRpWRjlfkBx9/r1A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gT/HWxyHwkkstNangg3ETk16uCp3ZxQW6V2aeBuClxo=; b=T8YtcLSL2fvrupmeZezOOFlGBmWbdXP6y6qJ08xBMFY2WNBHsoUl5BhqSt6AbPREju DKMtT4oguVD9VI1NIyKfIWlJ/MPOG8eR9tSldgNVQraRuolUemIhMLgIg7icUYb4plp+ LXzh0YnZ1NNaRfJSDN4hv7nw3N42x+/w4i3QWCKXy1gpwYxDJ/ejHghEZ8+wKPcDo9XS Lq1u2d100hxHb+psbGoPWe/t+r695VZUeoEQUVhg3xW6tO6q5Ahf0ydu9iP0xDf2vpxI tpYhdMABDEI7kxHP9h1A1BpZc503AH6HD28mb0vsjwM+Tpmhns4M1EnkjjYXdyLyXZUO L9wg== X-Gm-Message-State: AElRT7FxYltoRyFbwLdU+usBy7kHYwNyqWs2OZBU+RvkEL4w1ec3c5C4 HE4bUB3ZzpG/uoydfR66xbdo0lITWzpE2Ot+utAv2OOy X-Google-Smtp-Source: AG47ELuASP+R35Ax1nOILM0CWMkohy8HdikHIfrEtOPDKtQ8z7foVkHPJDCrD8ys73dG9oJf0B8CMWOUXwEcP04Lk5E= X-Received: by 2002:a24:d98d:: with SMTP id p135-v6mr1819758itg.106.1521199702121; Fri, 16 Mar 2018 04:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Fri, 16 Mar 2018 04:28:21 -0700 (PDT) In-Reply-To: <20180315190148.gc74gfdnttvoy3i5@bivouac.eciton.net> References: <20180315102826.10517-1-ard.biesheuvel@linaro.org> <20180315190148.gc74gfdnttvoy3i5@bivouac.eciton.net> From: Ard Biesheuvel Date: Fri, 16 Mar 2018 11:28:21 +0000 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , Marc Zyngier , Heyi Guo Subject: Re: [PATCH] ArmPkg/TimerDxe: remove workaround for KVM timer handling X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 11:21:58 -0000 Content-Type: text/plain; charset="UTF-8" On 15 March 2018 at 19:01, Leif Lindholm wrote: > On Thu, Mar 15, 2018 at 10:28:26AM +0000, Ard Biesheuvel wrote: >> When we first ported EDK2 to KVM/arm, we implemented a workaround for >> the quirky timer handling on the KVM side. This has been fixed in >> Linux commit f120cd6533d2 ("KVM: arm/arm64: timer: Allow the timer to >> control the active state") dated 23 June 2014, which was incorporated >> into Linux release 4.3. >> >> So almost 4 years later, it should be safe to drop this workaround on >> the EDK2 side. >> >> This reverts commit b1a633434ddc. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Ard Biesheuvel > > I'm happy with this, with Marc's Ack. > Reviewed-by: Leif Lindholm > > However, if this can affect old kernels running in vms, could you ping > cross-distro@lists.linaro.org as well, so it doesn't catch anyone by > surprise? > It will affects VMs running new firmware on ancient host kernels (and v4.2 *is* ancient when it comes to KVM/arm64 and server stuff imo) >> --- >> ArmPkg/Drivers/TimerDxe/TimerDxe.c | 1 - >> ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c | 10 ---------- >> 2 files changed, 11 deletions(-) >> >> diff --git a/ArmPkg/Drivers/TimerDxe/TimerDxe.c b/ArmPkg/Drivers/TimerDxe/TimerDxe.c >> index a3202fa056f3..bd616d2efc73 100644 >> --- a/ArmPkg/Drivers/TimerDxe/TimerDxe.c >> +++ b/ArmPkg/Drivers/TimerDxe/TimerDxe.c >> @@ -337,7 +337,6 @@ TimerInterruptHandler ( >> >> // Set next compare value >> ArmGenericTimerSetCompareVal (CompareValue); >> - ArmGenericTimerEnableTimer (); >> ArmInstructionSynchronizationBarrier (); >> } >> >> diff --git a/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c b/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c >> index 69a4ceb62db6..c941895a3574 100644 >> --- a/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c >> +++ b/ArmPkg/Library/ArmGenericTimerVirtCounterLib/ArmGenericTimerVirtCounterLib.c >> @@ -26,16 +26,6 @@ ArmGenericTimerEnableTimer ( >> >> TimerCtrlReg = ArmReadCntvCtl (); >> TimerCtrlReg |= ARM_ARCH_TIMER_ENABLE; >> - >> - // >> - // When running under KVM, we need to unmask the interrupt on the timer side >> - // as KVM will mask it when servicing the interrupt at the hypervisor level >> - // and delivering the virtual timer interrupt to the guest. Otherwise, the >> - // interrupt will fire again, trapping into the hypervisor again, etc. etc. >> - // This is scheduled to be fixed on the KVM side, but there is no harm in >> - // leaving this in once KVM gets fixed. >> - // >> - TimerCtrlReg &= ~ARM_ARCH_TIMER_IMASK; >> ArmWriteCntvCtl (TimerCtrlReg); >> } >> >> -- >> 2.15.1 >>