From: Marc Zyngier <maz@kernel.org>
To: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
Cc: linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, eauger@redhat.com,
miguel.luis@oracle.com, darren@os.amperecomputing.com,
scott@os.amperecomputing.com,
Christoffer Dall <Christoffer.Dall@arm.com>
Subject: Re: [PATCH 2/2] KVM: arm64: timers: Adjust CVAL of a ptimer across guest entry and exits
Date: Thu, 17 Aug 2023 09:27:38 +0100 [thread overview]
Message-ID: <87bkf6oyyt.wl-maz@kernel.org> (raw)
In-Reply-To: <20230817060314.535987-3-gankulkarni@os.amperecomputing.com>
[Fixing Christoffer's email address]
On Thu, 17 Aug 2023 07:03:14 +0100,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com> wrote:
>
> As per FEAT_ECV, when HCR_EL2.{E2H, TGE} == {1, 1}, Enhanced Counter
> Virtualization functionality is disabled and CNTPOFF_EL2 value is treated
> as zero. On VHE host, E2H and TGE are set, hence it is required
> to adjust CVAL by incrementing it by CNTPOFF_EL2 after guest
> exit to avoid false physical timer interrupts and also
> decrement/restore CVAL before the guest entry.
No, this is wrong. Neither E2H nor TGE have any impact on writing to
CNTPOFF_EL2, nor does it have an impact on CNTP_CVAL_EL0. Just read
the pseudocode to convince yourself.
CNTPOFF_EL2 is applied at exactly two points: when SW is reading
CNTPCT_EL0 from EL1 while {E2H,TGE}=={1, 0} and when the HW is
comparing CNTPCT_EL0 with the CNTP_CVAL_EL0. In both cases the offset
is subtracted from the counter. And that's the point where the running
EL matters. Which means that CNTPOFF_EL2 behaves exactly like
CNTVOFF_EL2. No ifs, no buts.
The behaviour you are describing tends to indicate that your HW is
applying CNTPOFF_EL2 to CVAL, which would be a gold plated bug.
It doesn't mean that the KVM code is correct either. I'm seeing pretty
bad behaviours on a machine without CNTPOFF_EL2. But what you are
suggesting is IMO a misunderstanding of the architecture.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
Cc: linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, eauger@redhat.com,
miguel.luis@oracle.com, darren@os.amperecomputing.com,
scott@os.amperecomputing.com,
Christoffer Dall <Christoffer.Dall@arm.com>
Subject: Re: [PATCH 2/2] KVM: arm64: timers: Adjust CVAL of a ptimer across guest entry and exits
Date: Thu, 17 Aug 2023 09:27:38 +0100 [thread overview]
Message-ID: <87bkf6oyyt.wl-maz@kernel.org> (raw)
In-Reply-To: <20230817060314.535987-3-gankulkarni@os.amperecomputing.com>
[Fixing Christoffer's email address]
On Thu, 17 Aug 2023 07:03:14 +0100,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com> wrote:
>
> As per FEAT_ECV, when HCR_EL2.{E2H, TGE} == {1, 1}, Enhanced Counter
> Virtualization functionality is disabled and CNTPOFF_EL2 value is treated
> as zero. On VHE host, E2H and TGE are set, hence it is required
> to adjust CVAL by incrementing it by CNTPOFF_EL2 after guest
> exit to avoid false physical timer interrupts and also
> decrement/restore CVAL before the guest entry.
No, this is wrong. Neither E2H nor TGE have any impact on writing to
CNTPOFF_EL2, nor does it have an impact on CNTP_CVAL_EL0. Just read
the pseudocode to convince yourself.
CNTPOFF_EL2 is applied at exactly two points: when SW is reading
CNTPCT_EL0 from EL1 while {E2H,TGE}=={1, 0} and when the HW is
comparing CNTPCT_EL0 with the CNTP_CVAL_EL0. In both cases the offset
is subtracted from the counter. And that's the point where the running
EL matters. Which means that CNTPOFF_EL2 behaves exactly like
CNTVOFF_EL2. No ifs, no buts.
The behaviour you are describing tends to indicate that your HW is
applying CNTPOFF_EL2 to CVAL, which would be a gold plated bug.
It doesn't mean that the KVM code is correct either. I'm seeing pretty
bad behaviours on a machine without CNTPOFF_EL2. But what you are
suggesting is IMO a misunderstanding of the architecture.
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
next prev parent reply other threads:[~2023-08-17 8:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 6:03 [PATCH 0/2] Avoid spurious ptimer interrupts for non-zero cntpoff Ganapatrao Kulkarni
2023-08-17 6:03 ` Ganapatrao Kulkarni
2023-08-17 6:03 ` [PATCH 1/2] KVM: arm64: timers: Move helper has_cntpoff to a header file Ganapatrao Kulkarni
2023-08-17 6:03 ` Ganapatrao Kulkarni
2023-08-17 6:03 ` [PATCH 2/2] KVM: arm64: timers: Adjust CVAL of a ptimer across guest entry and exits Ganapatrao Kulkarni
2023-08-17 6:03 ` Ganapatrao Kulkarni
2023-08-17 8:27 ` Marc Zyngier [this message]
2023-08-17 8:27 ` Marc Zyngier
2023-08-17 9:27 ` Ganapatrao Kulkarni
2023-08-17 9:27 ` Ganapatrao Kulkarni
2023-08-17 10:04 ` Marc Zyngier
2023-08-17 10:04 ` Marc Zyngier
2023-08-22 12:16 ` Marc Zyngier
2023-08-22 12:16 ` Marc Zyngier
2023-08-22 14:57 ` Ganapatrao Kulkarni
2023-08-22 14:57 ` Ganapatrao Kulkarni
2023-08-24 6:37 ` Ganapatrao Kulkarni
2023-08-24 6:37 ` Ganapatrao Kulkarni
2023-08-28 10:17 ` Marc Zyngier
2023-08-28 10:17 ` Marc Zyngier
2023-09-01 12:15 ` Ganapatrao Kulkarni
2023-09-01 12:15 ` Ganapatrao Kulkarni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bkf6oyyt.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Christoffer.Dall@arm.com \
--cc=darren@os.amperecomputing.com \
--cc=eauger@redhat.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.luis@oracle.com \
--cc=scott@os.amperecomputing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.