From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c09::241; helo=mail-wm0-x241.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 D8FCD22135D3D for ; Thu, 15 Mar 2018 11:55:30 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id 139so12570740wmn.2 for ; Thu, 15 Mar 2018 12:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=93qu9EYwfZ/aPSiB4tD0VMn+bi5avJ7BNXJMbM6u/cA=; b=RTfd/e411YZSS7TYkYtNd80RLlX0PYOQLtTejaVuDErWHMk3KMrwoFHmVePWgFkYH9 /DdRr4ARo89I4oIki0+Ngt3U+N4y4ZVNEGzLOmGTPlxJ5jUr9zSztMqLjM9o7ac4AwyJ eiS6ekVl55EXvDm+qfsuBqdpwjV9VrSU8jW28= 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:user-agent; bh=93qu9EYwfZ/aPSiB4tD0VMn+bi5avJ7BNXJMbM6u/cA=; b=pf/4AzX+4ANFgxAm4x1edwbwCBSCEymXLqrWJ2X/xHi7xdZmeNeJ09hfd/Cb3HkI2Y ER2VxdHwwkZstugYOwXquMyAghKLAgi7I4XrSufmKFbfFpC7gui+CuL+mPBAl2qRDM3f wX+OisP0qv71JCiUD4bHyKDSU8FpMPGonvZQX/+/UDp44DTiw2Pt+Qt2tMvnHP92fbED bugcYIeHBGNrWP0i7SEesyrc2icaxk5EYy5P1n3ZUXKfcsUt0VJAmPfW425nmk0p0X+V B12HtAijBm7OdpACTVJIdyJLUzlnRuyWlZKPJEJuh+b9WwzKTSVPypPpLd+DEDdMBiqG IDNA== X-Gm-Message-State: AElRT7G2sTrRIhcI78d/DJlnCTJwv7yMfOrVlepoBZ7wwMS6owQ8nmZW XOlnvLsZUmZhWus/DJYUtf1GpQ== X-Google-Smtp-Source: AG47ELtjUj3gUtQ55O95cJVgKCf9Ks19mzJdpZmv7zRgvsHlj8DVDlfRMc8cJVpRWBmkTo7ihTgN8A== X-Received: by 10.28.113.79 with SMTP id m76mr6109954wmc.27.1521140511219; Thu, 15 Mar 2018 12:01:51 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id o2sm5493204wro.31.2018.03.15.12.01.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 15 Mar 2018 12:01:49 -0700 (PDT) Date: Thu, 15 Mar 2018 19:01:48 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: edk2-devel@lists.01.org, lersek@redhat.com, marc.zyngier@arm.com, heyi.guo@linaro.org Message-ID: <20180315190148.gc74gfdnttvoy3i5@bivouac.eciton.net> References: <20180315102826.10517-1-ard.biesheuvel@linaro.org> MIME-Version: 1.0 In-Reply-To: <20180315102826.10517-1-ard.biesheuvel@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) 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: Thu, 15 Mar 2018 18:55:31 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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? / Leif > --- > 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 >