From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 9BEFC81EA6 for ; Fri, 20 Jan 2017 07:20:55 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id l66so63647696ioi.1 for ; Fri, 20 Jan 2017 07:20:55 -0800 (PST) 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=jzHjDTPxxv7ubcnaoWdb46cgAbrzOoX+Qx9pTYO3zJg=; b=j+RMPEFhlhhm/XryM94nh2GbvaxmBOmltaYupqVU4CMYAlVo4BvwkOTsKpAqHz0HGR jWMaZRYQ2epuavtAv5Mvf4brzRt1qH5cXWAqymbyP2BKXBkD83TAxReHwiyMjqIfCa/5 w9bkpnzpC9EdpM3vHIVYttlTeqQNBYmGiV1sI= 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=jzHjDTPxxv7ubcnaoWdb46cgAbrzOoX+Qx9pTYO3zJg=; b=MMrZeNb/ydDxM6hPTp7003xopSAzuT4UoU6oxtgmBEN7h7iB9gkqYENMGpWcPTbVFB Hs2I5VOWeRLirpAvmOLC0j79V++IR89inWjBnIbhGaF9FwR9u5JGElImqdhT34/JCPUg NszJg6i1OTKelhoPovtz4KYVUOUaV9ddqkoYHegksQy1r9uN/dF2I8BbFTdVmxabc/8d Cshr9N4dGSx7bc261jzWgwHJDiGYOCtLjhEeuvj6ipkaVHnt7fokqBbjFhVHclNatoN/ QCW2KzXui1I18KsCsWX+soQxhyfwuW7Km7EFH2Nt5mBP1hdHuKdbpF744PGcefvKisNw YvJA== X-Gm-Message-State: AIkVDXK+xWb880SEYQ8/dFo+4nQe34c839ncl8TR0eJ5G88+VpL+YWEpLBea6WY1DSPCNNh5gzVkSNeR2DAP+gp1 X-Received: by 10.107.12.150 with SMTP id 22mr12885011iom.138.1484925654894; Fri, 20 Jan 2017 07:20:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.144.135 with HTTP; Fri, 20 Jan 2017 07:20:54 -0800 (PST) In-Reply-To: <22373f4c-043b-3ee4-1c60-ecf2c7fa6845@arm.com> References: <1484922043-21762-1-git-send-email-ard.biesheuvel@linaro.org> <20170120144145.GB22152@leverpostej> <22373f4c-043b-3ee4-1c60-ecf2c7fa6845@arm.com> From: Ard Biesheuvel Date: Fri, 20 Jan 2017 15:20:54 +0000 Message-ID: To: Marc Zyngier Cc: Mark Rutland , "edk2-devel@lists.01.org" , Ryan Harkin , Leif Lindholm Subject: Re: [PATCH] ArmPkg/ArmGenericTimerVirtCounterLib: deal with broken generic timers X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 15:20:55 -0000 Content-Type: text/plain; charset=UTF-8 On 20 January 2017 at 15:06, Marc Zyngier wrote: > On 20/01/17 14:41, Mark Rutland wrote: >> [Adding Marc Zyngier] >> >> On Fri, Jan 20, 2017 at 02:20:43PM +0000, Ard Biesheuvel wrote: >>> Users of ArmGenericTimerVirtCounterLib may execute under virtualization, >>> which implies that they may be affected by core errata of the host. >>> >>> Some implementations of the ARM Generic Timer are affected by errata where >>> reads of the counter and reads or writes to the timer value may execute >>> incorrectly when issued around the time the counter is incremented by >>> the hardware. >> >> So far, there are at least two slightly different errata I've seen in >> this area: Freescale erratum A-008585, and Hisilicon erratum #161010101. >> >> The first has a workaround in upstream Linux, whereas the latter >> apparently requires a different workaround, and is currently under >> review. >> >> There may not be a one-size-fits-all solution, here. To that end, I >> would strongly suggest that we document precisely which errata we are >> trying to handle here. > > Also, is there any way that DT/ACPI could be used to identify the actual > erratum? When running a guest on my FSL box, my guest launch script adds > the required property to the guest DT for the kernel to pick it up. Not > as nice as a "one size fits all" method, but as Mark pointed out, such a > method may simply not exist... > DT should be feasible, given that the UEFI firmware for QEMU does consume the DT supplied to it. ACPI tables are produced by the firmware rather than consumed by it, so fortunately we don't need to care about those. So if a binding should be defined that describes this erratum, we could in fact use it to enable it rather than enable it unconditionally. Are we talking about just 'fsl,erratum-a008585' here? Or have additional ones been specified already? And is anyone aware if any work has been done on the QEMU side of this?