From: Marc Zyngier <marc.zyngier@arm.com>
To: Christoffer Dall <c.dall@virtualopensystems.com>
Cc: Will Deacon <Will.Deacon@arm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH v5 3/4] ARM: KVM: arch_timers: Add timer world switch
Date: Tue, 15 Jan 2013 11:10:43 +0000 [thread overview]
Message-ID: <50F53933.7050309@arm.com> (raw)
In-Reply-To: <CANM98qLsq7=PRNu4-5-N2GaAuLFOUfpy-yEWb6LpZri3WQ8JwA@mail.gmail.com>
On 14/01/13 22:08, Christoffer Dall wrote:
> On Mon, Jan 14, 2013 at 12:51 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 14/01/13 15:21, Will Deacon wrote:
>>> On Tue, Jan 08, 2013 at 06:43:27PM +0000, Christoffer Dall wrote:
>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> Do the necessary save/restore dance for the timers in the world
>>>> switch code. In the process, allow the guest to read the physical
>>>> counter, which is useful for its own clock_event_device.
>>>
>>> [...]
>>>
>>>> @@ -476,6 +513,7 @@ vcpu .req r0 @ vcpu pointer always in r0
>>>> * for the host.
>>>> *
>>>> * Assumes vcpu pointer in vcpu reg
>>>> + * Clobbers r2-r4
>>>> */
>>>> .macro restore_timer_state
>>>> @ Disallow physical timer access for the guest
>>>> @@ -484,6 +522,30 @@ vcpu .req r0 @ vcpu pointer always in r0
>>>> orr r2, r2, #CNTHCTL_PL1PCTEN
>>>> bic r2, r2, #CNTHCTL_PL1PCEN
>>>> mcr p15, 4, r2, c14, c1, 0 @ CNTHCTL
>>>> +
>>>> +#ifdef CONFIG_KVM_ARM_TIMER
>>>> + ldr r4, [vcpu, #VCPU_KVM]
>>>> + ldr r2, [r4, #KVM_TIMER_ENABLED]
>>>> + cmp r2, #0
>>>> + beq 1f
>>>> +
>>>> + ldr r2, [r4, #KVM_TIMER_CNTVOFF]
>>>> + ldr r3, [r4, #(KVM_TIMER_CNTVOFF + 4)]
>>>> + mcrr p15, 4, r2, r3, c14 @ CNTVOFF
>>>> + isb
>>>> +
>>>> + ldr r4, =VCPU_TIMER_CNTV_CVAL
>>>> + add vcpu, vcpu, r4
>>>> + ldrd r2, r3, [vcpu]
>>>> + sub vcpu, vcpu, r4
>>>> + mcrr p15, 3, r2, r3, c14 @ CNTV_CVAL
>>>> +
>>>> + ldr r2, [vcpu, #VCPU_TIMER_CNTV_CTL]
>>>> + and r2, r2, #3
>>>> + mcr p15, 0, r2, c14, c3, 1 @ CNTV_CTL
>>>> + isb
>>>
>>> How many of these isbs are actually needed, given that we're going to make
>>> an exception return to the guest? The last one certainly looks redundant and
>>> I can't see the need for ordering CNTVOFF vs CNTV_CVAL. I can see an
>>> argument to putting one *before* CNTV_CTL, but you don't have one there!
>>
>> CNTVOFF directly influences whether or not CNTV_CVAL will trigger or
>> not. Maybe I'm just being paranoid and moving the isb after CNTV_CVAL is
>> enough.
>>
>> The last one is definitively superfluous.
>>
>
> can't we also get rid of the isb on the return path then?
>
> do you agree with this patch:
>
> diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
> index 57cfa84..7e6eedf 100644
> --- a/arch/arm/kvm/interrupts_head.S
> +++ b/arch/arm/kvm/interrupts_head.S
> @@ -492,7 +492,6 @@ vcpu .req r0 @ vcpu pointer always in r0
> str r2, [vcpu, #VCPU_TIMER_CNTV_CTL]
> bic r2, #1 @ Clear ENABLE
> mcr p15, 0, r2, c14, c3, 1 @ CNTV_CTL
> - isb
This isb is required. Otherwise you have no guarantee about how recent
the next CNTV_CVAL read is (could be speculated).
> mrrc p15, 3, r2, r3, c14 @ CNTV_CVAL
> ldr r4, =VCPU_TIMER_CNTV_CVAL
> @@ -532,18 +531,17 @@ vcpu .req r0 @ vcpu pointer always in r0
> ldr r2, [r4, #KVM_TIMER_CNTVOFF]
> ldr r3, [r4, #(KVM_TIMER_CNTVOFF + 4)]
> mcrr p15, 4, r2, r3, c14 @ CNTVOFF
> - isb
>
> ldr r4, =VCPU_TIMER_CNTV_CVAL
> add vcpu, vcpu, r4
> ldrd r2, r3, [vcpu]
> sub vcpu, vcpu, r4
> mcrr p15, 3, r2, r3, c14 @ CNTV_CVAL
> + isb
>
> ldr r2, [vcpu, #VCPU_TIMER_CNTV_CTL]
> and r2, r2, #3
> mcr p15, 0, r2, c14, c3, 1 @ CNTV_CTL
> - isb
> 1:
> #endif
> .endm
This part is OK.
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2013-01-15 11:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 18:43 [PATCH v5 0/4] KVM/ARM Architected Timers support Christoffer Dall
2013-01-08 18:43 ` [PATCH v5 1/4] ARM: arch_timers: switch to physical timers if HYP mode is available Christoffer Dall
2013-01-08 18:43 ` [PATCH v5 2/4] ARM: KVM: arch_timers: Add guest timer core support Christoffer Dall
2013-01-14 15:18 ` Will Deacon
2013-01-14 19:19 ` Christoffer Dall
2013-01-15 11:07 ` Marc Zyngier
2013-01-15 14:32 ` Christoffer Dall
2013-01-08 18:43 ` [PATCH v5 3/4] ARM: KVM: arch_timers: Add timer world switch Christoffer Dall
2013-01-14 15:21 ` Will Deacon
2013-01-14 17:51 ` Marc Zyngier
2013-01-14 22:08 ` Christoffer Dall
2013-01-14 22:25 ` Will Deacon
2013-01-15 11:10 ` Marc Zyngier [this message]
2013-01-08 18:43 ` [PATCH v5 4/4] ARM: KVM: arch_timers: Wire the init code and config option Christoffer Dall
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=50F53933.7050309@arm.com \
--to=marc.zyngier@arm.com \
--cc=Will.Deacon@arm.com \
--cc=c.dall@virtualopensystems.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox