From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D368C4338F for ; Fri, 30 Jul 2021 16:18:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 017D860EFD for ; Fri, 30 Jul 2021 16:18:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229587AbhG3QSG (ORCPT ); Fri, 30 Jul 2021 12:18:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:51180 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229477AbhG3QSF (ORCPT ); Fri, 30 Jul 2021 12:18:05 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8B7FD60EE2; Fri, 30 Jul 2021 16:18:00 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m9VCw-0022rE-EI; Fri, 30 Jul 2021 17:17:58 +0100 Date: Fri, 30 Jul 2021 17:17:57 +0100 Message-ID: <87wnp722tm.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, Paolo Bonzini , Sean Christopherson , Peter Shier , Jim Mattson , David Matlack , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Andrew Jones Subject: Re: [PATCH v5 11/13] KVM: arm64: Provide userspace access to the physical counter offset In-Reply-To: References: <20210729173300.181775-1-oupton@google.com> <20210729173300.181775-12-oupton@google.com> <875yws2h5w.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oupton@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, seanjc@google.com, pshier@google.com, jmattson@google.com, dmatlack@google.com, ricarkol@google.com, jingzhangos@google.com, rananta@google.com, james.morse@arm.com, Alexandru.Elisei@arm.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, drjones@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, 30 Jul 2021 16:22:01 +0100, Oliver Upton wrote: > > On Fri, Jul 30, 2021 at 4:08 AM Marc Zyngier wrote: > > > FEAT_ECV provides a guest physical counter-timer offset register > > > (CNTPOFF_EL2), but ECV-enabled hardware is nonexistent at the time of > > > writing so support for it was elided for the sake of the author :) > > > > You seem to have done most the work for that, and there are SW models > > out there that implement ECV. If anything, the ECV support should come > > first, and its emulation only as a poor man's workaround. > > > > It is also good to show silicon vendors that they suck at providing > > useful features, and pointing them to the code that would use these > > features *is* an incentive. > > Lol, then so be it. I'll add ECV support to this series. What can I > test with, though? I don't recall QEMU supporting ECV last I checked.. You want the ARM FVP model, or maybe even the Foundation model. It has support all the way to ARMv8.7 apparently. I personally use the FVP, get in touch offline and I'll help you with the setup. In general, I tend to trust the ARM models a lot more than QEMU for the quality of the emulation. You can tune it in some bizarre way (the cache modelling is terrifying), and it will definitely do all kind of crazy reordering and speculation. > > > I really dislike the fallback to !vhe here. I'd rather you > > special-case the emulated ptimer in the VHE case: > > > > if (has_vhe()) { > > map->direct_vtimer = vcpu_vtimer(vcpu); > > if (!timer_get_offset(vcpu_ptimer(vcpu))) > > map->direct_ptimer = vcpu_ptimer(vcpu); > > map->emul_ptimer = NULL; > > } else { > > map->direct_ptimer = NULL; > > map->emul_ptimer = vcpu_ptimer(vcpu); > > } > > } else { > > Ack. > > > and you can drop the timer_emulation_required() helper which doesn't > > serve any purpose. > > Especially if I add ECV to this series, I'd prefer to carry it than > open-code the check for CNTPOFF && !ECV in get_timer_map(). Do you > concur? I can tighten it to ptimer_emulation_required() and avoid > taking an arch_timer context if you prefer. Sure, whatever you prefer. I'm not set on one way or another, but in the above case, it was clearly easier to get rid of the helper. > > the counter read can (and will) be speculated, > > so you definitely need an ISB before the access. Please also look at > > __arch_counter_get_cntpct() and arch_counter_enforce_ordering(). > > Wouldn't it be up to the guest to decide if it wants the counter to be > speculated or not? I debated this a bit myself in the implementation, > as we would trap both ordered and un-ordered reads. Well, no way to > detect it :) There has been a trap, so that already was a context synchronisation event. but it would be pretty common for the counter to be speculated way early, when entering EL2. That's not the end of the world, but that's not an accurate emulation. You'd want it to be as close as possible to the reentry point into the guest. Thanks, M. -- Without deviation from the norm, progress is not possible. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0ACBEC4338F for ; Fri, 30 Jul 2021 16:18:06 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 758F060F3A for ; Fri, 30 Jul 2021 16:18:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 758F060F3A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id E67F44A524; Fri, 30 Jul 2021 12:18:04 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgyiDC0wHfRE; Fri, 30 Jul 2021 12:18:03 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A436B4B0C6; Fri, 30 Jul 2021 12:18:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1289D406E7 for ; Fri, 30 Jul 2021 12:18:03 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJsuP2x9vSBd for ; Fri, 30 Jul 2021 12:18:01 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id C49AC4A524 for ; Fri, 30 Jul 2021 12:18:01 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8B7FD60EE2; Fri, 30 Jul 2021 16:18:00 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m9VCw-0022rE-EI; Fri, 30 Jul 2021 17:17:58 +0100 Date: Fri, 30 Jul 2021 17:17:57 +0100 Message-ID: <87wnp722tm.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Subject: Re: [PATCH v5 11/13] KVM: arm64: Provide userspace access to the physical counter offset In-Reply-To: References: <20210729173300.181775-1-oupton@google.com> <20210729173300.181775-12-oupton@google.com> <875yws2h5w.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oupton@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, seanjc@google.com, pshier@google.com, jmattson@google.com, dmatlack@google.com, ricarkol@google.com, jingzhangos@google.com, rananta@google.com, james.morse@arm.com, Alexandru.Elisei@arm.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, drjones@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kvm@vger.kernel.org, Sean Christopherson , Peter Shier , Raghavendra Rao Anata , David Matlack , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Fri, 30 Jul 2021 16:22:01 +0100, Oliver Upton wrote: > > On Fri, Jul 30, 2021 at 4:08 AM Marc Zyngier wrote: > > > FEAT_ECV provides a guest physical counter-timer offset register > > > (CNTPOFF_EL2), but ECV-enabled hardware is nonexistent at the time of > > > writing so support for it was elided for the sake of the author :) > > > > You seem to have done most the work for that, and there are SW models > > out there that implement ECV. If anything, the ECV support should come > > first, and its emulation only as a poor man's workaround. > > > > It is also good to show silicon vendors that they suck at providing > > useful features, and pointing them to the code that would use these > > features *is* an incentive. > > Lol, then so be it. I'll add ECV support to this series. What can I > test with, though? I don't recall QEMU supporting ECV last I checked.. You want the ARM FVP model, or maybe even the Foundation model. It has support all the way to ARMv8.7 apparently. I personally use the FVP, get in touch offline and I'll help you with the setup. In general, I tend to trust the ARM models a lot more than QEMU for the quality of the emulation. You can tune it in some bizarre way (the cache modelling is terrifying), and it will definitely do all kind of crazy reordering and speculation. > > > I really dislike the fallback to !vhe here. I'd rather you > > special-case the emulated ptimer in the VHE case: > > > > if (has_vhe()) { > > map->direct_vtimer = vcpu_vtimer(vcpu); > > if (!timer_get_offset(vcpu_ptimer(vcpu))) > > map->direct_ptimer = vcpu_ptimer(vcpu); > > map->emul_ptimer = NULL; > > } else { > > map->direct_ptimer = NULL; > > map->emul_ptimer = vcpu_ptimer(vcpu); > > } > > } else { > > Ack. > > > and you can drop the timer_emulation_required() helper which doesn't > > serve any purpose. > > Especially if I add ECV to this series, I'd prefer to carry it than > open-code the check for CNTPOFF && !ECV in get_timer_map(). Do you > concur? I can tighten it to ptimer_emulation_required() and avoid > taking an arch_timer context if you prefer. Sure, whatever you prefer. I'm not set on one way or another, but in the above case, it was clearly easier to get rid of the helper. > > the counter read can (and will) be speculated, > > so you definitely need an ISB before the access. Please also look at > > __arch_counter_get_cntpct() and arch_counter_enforce_ordering(). > > Wouldn't it be up to the guest to decide if it wants the counter to be > speculated or not? I debated this a bit myself in the implementation, > as we would trap both ordered and un-ordered reads. Well, no way to > detect it :) There has been a trap, so that already was a context synchronisation event. but it would be pretty common for the counter to be speculated way early, when entering EL2. That's not the end of the world, but that's not an accurate emulation. You'd want it to be as close as possible to the reentry point into the guest. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2321CC4338F for ; Fri, 30 Jul 2021 16:20:19 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DC27360F4A for ; Fri, 30 Jul 2021 16:20:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DC27360F4A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=er+fjZlz/zTOZiSLsbmtW7BQPtMnc2ZDQ1WeyVJQgNk=; b=i7BuQkdj5i8Ebz b/yHlEi/yZnmWPmzGa6H1xgHzqbeEstqkjLW0swKfPzxW9ZzXaiN9wE7n81STLzL7kWHBODAUG40W aOkJ6OvgFaFii18wlyru/MNoKRFbzHdcH3E3O70eWFi1hjrYbwQLu4QAru0Fq34beWMmXFbGfebl3 2/q7o7OrGN9ajR3s6Ywz1GfeWjpHU4GP6J5ahc5QZ1x2cp0wXt7MDrjWcA2XOXLB6Exxpw+vYERzP dPybE+P0Y3CvyzF6LwY9fkClE3G+NHaQm6ibcYa6rKX1/Sw5ahLjrRaKy4QJkZ2E4iEt8Xa5hZk5D /nBK69A/I2D9xyu7sfhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9VD6-009T5c-5J; Fri, 30 Jul 2021 16:18:08 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9VCy-009T4q-VC for linux-arm-kernel@lists.infradead.org; Fri, 30 Jul 2021 16:18:06 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8B7FD60EE2; Fri, 30 Jul 2021 16:18:00 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m9VCw-0022rE-EI; Fri, 30 Jul 2021 17:17:58 +0100 Date: Fri, 30 Jul 2021 17:17:57 +0100 Message-ID: <87wnp722tm.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, Paolo Bonzini , Sean Christopherson , Peter Shier , Jim Mattson , David Matlack , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Andrew Jones Subject: Re: [PATCH v5 11/13] KVM: arm64: Provide userspace access to the physical counter offset In-Reply-To: References: <20210729173300.181775-1-oupton@google.com> <20210729173300.181775-12-oupton@google.com> <875yws2h5w.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oupton@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, seanjc@google.com, pshier@google.com, jmattson@google.com, dmatlack@google.com, ricarkol@google.com, jingzhangos@google.com, rananta@google.com, james.morse@arm.com, Alexandru.Elisei@arm.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, drjones@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210730_091801_082034_EE02776A X-CRM114-Status: GOOD ( 39.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 30 Jul 2021 16:22:01 +0100, Oliver Upton wrote: > > On Fri, Jul 30, 2021 at 4:08 AM Marc Zyngier wrote: > > > FEAT_ECV provides a guest physical counter-timer offset register > > > (CNTPOFF_EL2), but ECV-enabled hardware is nonexistent at the time of > > > writing so support for it was elided for the sake of the author :) > > > > You seem to have done most the work for that, and there are SW models > > out there that implement ECV. If anything, the ECV support should come > > first, and its emulation only as a poor man's workaround. > > > > It is also good to show silicon vendors that they suck at providing > > useful features, and pointing them to the code that would use these > > features *is* an incentive. > > Lol, then so be it. I'll add ECV support to this series. What can I > test with, though? I don't recall QEMU supporting ECV last I checked.. You want the ARM FVP model, or maybe even the Foundation model. It has support all the way to ARMv8.7 apparently. I personally use the FVP, get in touch offline and I'll help you with the setup. In general, I tend to trust the ARM models a lot more than QEMU for the quality of the emulation. You can tune it in some bizarre way (the cache modelling is terrifying), and it will definitely do all kind of crazy reordering and speculation. > > > I really dislike the fallback to !vhe here. I'd rather you > > special-case the emulated ptimer in the VHE case: > > > > if (has_vhe()) { > > map->direct_vtimer = vcpu_vtimer(vcpu); > > if (!timer_get_offset(vcpu_ptimer(vcpu))) > > map->direct_ptimer = vcpu_ptimer(vcpu); > > map->emul_ptimer = NULL; > > } else { > > map->direct_ptimer = NULL; > > map->emul_ptimer = vcpu_ptimer(vcpu); > > } > > } else { > > Ack. > > > and you can drop the timer_emulation_required() helper which doesn't > > serve any purpose. > > Especially if I add ECV to this series, I'd prefer to carry it than > open-code the check for CNTPOFF && !ECV in get_timer_map(). Do you > concur? I can tighten it to ptimer_emulation_required() and avoid > taking an arch_timer context if you prefer. Sure, whatever you prefer. I'm not set on one way or another, but in the above case, it was clearly easier to get rid of the helper. > > the counter read can (and will) be speculated, > > so you definitely need an ISB before the access. Please also look at > > __arch_counter_get_cntpct() and arch_counter_enforce_ordering(). > > Wouldn't it be up to the guest to decide if it wants the counter to be > speculated or not? I debated this a bit myself in the implementation, > as we would trap both ordered and un-ordered reads. Well, no way to > detect it :) There has been a trap, so that already was a context synchronisation event. but it would be pretty common for the counter to be speculated way early, when entering EL2. That's not the end of the world, but that's not an accurate emulation. You'd want it to be as close as possible to the reentry point into the guest. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel