* [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements @ 2019-12-11 21:13 Jeff Kubascik 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset Jeff Kubascik ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Jeff Kubascik @ 2019-12-11 21:13 UTC (permalink / raw) To: xen-devel Cc: Stewart Hildebrand, Volodymyr Babchuk, Stefano Stabellini, Julien Grall This patch set improves the emulation of the physical timer by removing the physical timer offset and sign extend the TimerValue to better match the behavior described in the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4. Changes in v2: - Update commit message to specify reference manual version and section - Change physical timer cval to hold hardware value - Make sure to sign extend TimerValue on writes. This was done by first casting the r pointer to (int32_t *), dereferencing it, then casting to uint64_t. Please let me know if there is a more correct way to do this Changes in v3: - Split TimerValue sign extension fix into separate patch - Update commit message to mention physical timer cleanup - Removed physical timer cval initialization line - Changed TimerValue sign extension to (uint64_t)(int32_t)*r - Account for condition where cval < boot_count Jeff Kubascik (2): xen/arm: remove physical timer offset xen/arm: sign extend writes to TimerValue xen/arch/arm/vtimer.c | 34 ++++++++++++++++++---------------- xen/include/asm-arm/domain.h | 3 --- 2 files changed, 18 insertions(+), 19 deletions(-) -- 2.17.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset 2019-12-11 21:13 [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements Jeff Kubascik @ 2019-12-11 21:13 ` Jeff Kubascik 2019-12-18 14:20 ` Julien Grall 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue Jeff Kubascik 2020-01-16 21:25 ` [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements Julien Grall 2 siblings, 1 reply; 12+ messages in thread From: Jeff Kubascik @ 2019-12-11 21:13 UTC (permalink / raw) To: xen-devel Cc: Stewart Hildebrand, Volodymyr Babchuk, Stefano Stabellini, Julien Grall The physical timer traps apply an offset so that time starts at 0 for the guest. However, this offset is not currently applied to the physical counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4 Timers, the "Offset" between the counter and timer should be zero for a physical timer. This removes the offset to make the timer and counter consistent. This also cleans up the physical timer implementation to better match the virtual timer - both cval's now hold the hardware value. Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> --- xen/arch/arm/vtimer.c | 34 ++++++++++++++++++---------------- xen/include/asm-arm/domain.h | 3 --- 2 files changed, 18 insertions(+), 19 deletions(-) diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c index e6aebdac9e..21b98ec20a 100644 --- a/xen/arch/arm/vtimer.c +++ b/xen/arch/arm/vtimer.c @@ -62,7 +62,6 @@ static void virt_timer_expired(void *data) int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) { - d->arch.phys_timer_base.offset = NOW(); d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0); d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset - boot_count); do_div(d->time_offset_seconds, 1000000000); @@ -108,7 +107,6 @@ int vcpu_vtimer_init(struct vcpu *v) init_timer(&t->timer, phys_timer_expired, t, v->processor); t->ctl = 0; - t->cval = NOW(); t->irq = d0 ? timer_get_irq(TIMER_PHYS_NONSECURE_PPI) : GUEST_TIMER_PHYS_NS_PPI; @@ -167,6 +165,7 @@ void virt_timer_restore(struct vcpu *v) static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool read) { struct vcpu *v = current; + s_time_t expires; if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) return false; @@ -184,8 +183,9 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool read) if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) { - set_timer(&v->arch.phys_timer.timer, - v->arch.phys_timer.cval + v->domain->arch.phys_timer_base.offset); + expires = v->arch.phys_timer.cval > boot_count + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; + set_timer(&v->arch.phys_timer.timer, expires); } else stop_timer(&v->arch.phys_timer.timer); @@ -197,26 +197,27 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, bool read) { struct vcpu *v = current; - s_time_t now; + uint64_t cntpct; + s_time_t expires; if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) return false; - now = NOW() - v->domain->arch.phys_timer_base.offset; + cntpct = get_cycles(); if ( read ) { - *r = (uint32_t)(ns_to_ticks(v->arch.phys_timer.cval - now) & 0xffffffffull); + *r = (uint32_t)((v->arch.phys_timer.cval - cntpct) & 0xffffffffull); } else { - v->arch.phys_timer.cval = now + ticks_to_ns(*r); + v->arch.phys_timer.cval = cntpct + *r; if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) { v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; - set_timer(&v->arch.phys_timer.timer, - v->arch.phys_timer.cval + - v->domain->arch.phys_timer_base.offset); + expires = v->arch.phys_timer.cval > boot_count + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; + set_timer(&v->arch.phys_timer.timer, expires); } } return true; @@ -226,23 +227,24 @@ static bool vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r, bool read) { struct vcpu *v = current; + s_time_t expires; if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) return false; if ( read ) { - *r = ns_to_ticks(v->arch.phys_timer.cval); + *r = v->arch.phys_timer.cval; } else { - v->arch.phys_timer.cval = ticks_to_ns(*r); + v->arch.phys_timer.cval = *r; if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) { v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; - set_timer(&v->arch.phys_timer.timer, - v->arch.phys_timer.cval + - v->domain->arch.phys_timer_base.offset); + expires = v->arch.phys_timer.cval > boot_count + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; + set_timer(&v->arch.phys_timer.timer, expires); } } return true; diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index f3f3fb7d7f..adc7fe7210 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -65,9 +65,6 @@ struct arch_domain RELMEM_done, } relmem; - struct { - uint64_t offset; - } phys_timer_base; struct { uint64_t offset; } virt_timer_base; -- 2.17.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset Jeff Kubascik @ 2019-12-18 14:20 ` Julien Grall 2020-01-17 21:24 ` Jeff Kubascik 0 siblings, 1 reply; 12+ messages in thread From: Julien Grall @ 2019-12-18 14:20 UTC (permalink / raw) To: Jeff Kubascik, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk Hi Jeff, On 11/12/2019 21:13, Jeff Kubascik wrote: > The physical timer traps apply an offset so that time starts at 0 for > the guest. However, this offset is not currently applied to the physical > counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section > D11.2.4 Timers, the "Offset" between the counter and timer should be > zero for a physical timer. This removes the offset to make the timer and > counter consistent. > > This also cleans up the physical timer implementation to better match > the virtual timer - both cval's now hold the hardware value. > > Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> > --- > xen/arch/arm/vtimer.c | 34 ++++++++++++++++++---------------- > xen/include/asm-arm/domain.h | 3 --- > 2 files changed, 18 insertions(+), 19 deletions(-) > > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c > index e6aebdac9e..21b98ec20a 100644 > --- a/xen/arch/arm/vtimer.c > +++ b/xen/arch/arm/vtimer.c > @@ -62,7 +62,6 @@ static void virt_timer_expired(void *data) > > int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) > { > - d->arch.phys_timer_base.offset = NOW(); > d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0); > d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset - boot_count); > do_div(d->time_offset_seconds, 1000000000); > @@ -108,7 +107,6 @@ int vcpu_vtimer_init(struct vcpu *v) > > init_timer(&t->timer, phys_timer_expired, t, v->processor); > t->ctl = 0; > - t->cval = NOW(); > t->irq = d0 > ? timer_get_irq(TIMER_PHYS_NONSECURE_PPI) > : GUEST_TIMER_PHYS_NS_PPI; > @@ -167,6 +165,7 @@ void virt_timer_restore(struct vcpu *v) > static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool read) > { > struct vcpu *v = current; > + s_time_t expires; > > if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) > return false; > @@ -184,8 +183,9 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool read) > > if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) > { > - set_timer(&v->arch.phys_timer.timer, > - v->arch.phys_timer.cval + v->domain->arch.phys_timer_base.offset); > + expires = v->arch.phys_timer.cval > boot_count > + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; > + set_timer(&v->arch.phys_timer.timer, expires); > } > else > stop_timer(&v->arch.phys_timer.timer); > @@ -197,26 +197,27 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, > bool read) > { > struct vcpu *v = current; > - s_time_t now; > + uint64_t cntpct; > + s_time_t expires; > > if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) > return false; > > - now = NOW() - v->domain->arch.phys_timer_base.offset; > + cntpct = get_cycles(); > > if ( read ) > { > - *r = (uint32_t)(ns_to_ticks(v->arch.phys_timer.cval - now) & 0xffffffffull); > + *r = (uint32_t)((v->arch.phys_timer.cval - cntpct) & 0xffffffffull); > } > else > { > - v->arch.phys_timer.cval = now + ticks_to_ns(*r); > + v->arch.phys_timer.cval = cntpct + *r; > if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) > { > v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; > - set_timer(&v->arch.phys_timer.timer, > - v->arch.phys_timer.cval + > - v->domain->arch.phys_timer_base.offset); > + expires = v->arch.phys_timer.cval > boot_count > + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; You probably want a comment to explain why you set to 0 here. > + set_timer(&v->arch.phys_timer.timer, expires); > } > } > return true; > @@ -226,23 +227,24 @@ static bool vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r, > bool read) > { > struct vcpu *v = current; > + s_time_t expires; > > if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) > return false; > > if ( read ) > { > - *r = ns_to_ticks(v->arch.phys_timer.cval); > + *r = v->arch.phys_timer.cval; > } > else > { > - v->arch.phys_timer.cval = ticks_to_ns(*r); > + v->arch.phys_timer.cval = *r; > if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) > { > v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; > - set_timer(&v->arch.phys_timer.timer, > - v->arch.phys_timer.cval + > - v->domain->arch.phys_timer_base.offset); > + expires = v->arch.phys_timer.cval > boot_count > + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; Same here. But I am wondering whether we could factor this code in a function. This would avoid code duplication and make the code simpler. This can be done as a follow-up as we may want to backport the fix. > + set_timer(&v->arch.phys_timer.timer, expires); > } > } > return true; > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h > index f3f3fb7d7f..adc7fe7210 100644 > --- a/xen/include/asm-arm/domain.h > +++ b/xen/include/asm-arm/domain.h > @@ -65,9 +65,6 @@ struct arch_domain > RELMEM_done, > } relmem; > > - struct { > - uint64_t offset; > - } phys_timer_base; > struct { > uint64_t offset; > } virt_timer_base; > Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset 2019-12-18 14:20 ` Julien Grall @ 2020-01-17 21:24 ` Jeff Kubascik 2020-01-23 12:28 ` Julien Grall 0 siblings, 1 reply; 12+ messages in thread From: Jeff Kubascik @ 2020-01-17 21:24 UTC (permalink / raw) To: Julien Grall, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk On 12/18/2019 9:20 AM, Julien Grall wrote: > Hi Jeff, > > On 11/12/2019 21:13, Jeff Kubascik wrote: >> The physical timer traps apply an offset so that time starts at 0 for >> the guest. However, this offset is not currently applied to the physical >> counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section >> D11.2.4 Timers, the "Offset" between the counter and timer should be >> zero for a physical timer. This removes the offset to make the timer and >> counter consistent. >> >> This also cleans up the physical timer implementation to better match >> the virtual timer - both cval's now hold the hardware value. >> >> Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> >> --- >> xen/arch/arm/vtimer.c | 34 ++++++++++++++++++---------------- >> xen/include/asm-arm/domain.h | 3 --- >> 2 files changed, 18 insertions(+), 19 deletions(-) >> >> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c >> index e6aebdac9e..21b98ec20a 100644 >> --- a/xen/arch/arm/vtimer.c >> +++ b/xen/arch/arm/vtimer.c >> @@ -62,7 +62,6 @@ static void virt_timer_expired(void *data) >> >> int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) >> { >> - d->arch.phys_timer_base.offset = NOW(); >> d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0); >> d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset - boot_count); >> do_div(d->time_offset_seconds, 1000000000); >> @@ -108,7 +107,6 @@ int vcpu_vtimer_init(struct vcpu *v) >> >> init_timer(&t->timer, phys_timer_expired, t, v->processor); >> t->ctl = 0; >> - t->cval = NOW(); >> t->irq = d0 >> ? timer_get_irq(TIMER_PHYS_NONSECURE_PPI) >> : GUEST_TIMER_PHYS_NS_PPI; >> @@ -167,6 +165,7 @@ void virt_timer_restore(struct vcpu *v) >> static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool read) >> { >> struct vcpu *v = current; >> + s_time_t expires; >> >> if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) >> return false; >> @@ -184,8 +183,9 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool read) >> >> if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) >> { >> - set_timer(&v->arch.phys_timer.timer, >> - v->arch.phys_timer.cval + v->domain->arch.phys_timer_base.offset); >> + expires = v->arch.phys_timer.cval > boot_count >> + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; >> + set_timer(&v->arch.phys_timer.timer, expires); >> } >> else >> stop_timer(&v->arch.phys_timer.timer); >> @@ -197,26 +197,27 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, >> bool read) >> { >> struct vcpu *v = current; >> - s_time_t now; >> + uint64_t cntpct; >> + s_time_t expires; >> >> if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) >> return false; >> >> - now = NOW() - v->domain->arch.phys_timer_base.offset; >> + cntpct = get_cycles(); >> >> if ( read ) >> { >> - *r = (uint32_t)(ns_to_ticks(v->arch.phys_timer.cval - now) & 0xffffffffull); >> + *r = (uint32_t)((v->arch.phys_timer.cval - cntpct) & 0xffffffffull); >> } >> else >> { >> - v->arch.phys_timer.cval = now + ticks_to_ns(*r); >> + v->arch.phys_timer.cval = cntpct + *r; >> if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) >> { >> v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; >> - set_timer(&v->arch.phys_timer.timer, >> - v->arch.phys_timer.cval + >> - v->domain->arch.phys_timer_base.offset); >> + expires = v->arch.phys_timer.cval > boot_count >> + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; > > You probably want a comment to explain why you set to 0 here. This code is repeated in 3 places - it probably doesn't make sense to have 3 duplicate comments as well. I think it would fit well with your function suggestion below. >> + set_timer(&v->arch.phys_timer.timer, expires); >> } >> } >> return true; >> @@ -226,23 +227,24 @@ static bool vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r, >> bool read) >> { >> struct vcpu *v = current; >> + s_time_t expires; >> >> if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) >> return false; >> >> if ( read ) >> { >> - *r = ns_to_ticks(v->arch.phys_timer.cval); >> + *r = v->arch.phys_timer.cval; >> } >> else >> { >> - v->arch.phys_timer.cval = ticks_to_ns(*r); >> + v->arch.phys_timer.cval = *r; >> if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) >> { >> v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; >> - set_timer(&v->arch.phys_timer.timer, >> - v->arch.phys_timer.cval + >> - v->domain->arch.phys_timer_base.offset); >> + expires = v->arch.phys_timer.cval > boot_count >> + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; > > Same here. But I am wondering whether we could factor this code in a > function. This would avoid code duplication and make the code simpler. > > This can be done as a follow-up as we may want to backport the fix. This is a great idea. However, I would consider this further scope creep for this patch set - I think what is here is already a great improvement. I am currently focused on wrapping up a project; unfortunately, this change would be low on the priority list for me and I may not be able to get to it. >> + set_timer(&v->arch.phys_timer.timer, expires); >> } >> } >> return true; >> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h >> index f3f3fb7d7f..adc7fe7210 100644 >> --- a/xen/include/asm-arm/domain.h >> +++ b/xen/include/asm-arm/domain.h >> @@ -65,9 +65,6 @@ struct arch_domain >> RELMEM_done, >> } relmem; >> >> - struct { >> - uint64_t offset; >> - } phys_timer_base; >> struct { >> uint64_t offset; >> } virt_timer_base; >> > > Cheers, > > -- > Julien Grall > Sincerely, Jeff Kubascik _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset 2020-01-17 21:24 ` Jeff Kubascik @ 2020-01-23 12:28 ` Julien Grall 0 siblings, 0 replies; 12+ messages in thread From: Julien Grall @ 2020-01-23 12:28 UTC (permalink / raw) To: Jeff Kubascik, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk Hi, On 17/01/2020 21:24, Jeff Kubascik wrote: > On 12/18/2019 9:20 AM, Julien Grall wrote: >> Hi Jeff, >> >> On 11/12/2019 21:13, Jeff Kubascik wrote: >>> The physical timer traps apply an offset so that time starts at 0 for >>> the guest. However, this offset is not currently applied to the physical >>> counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section >>> D11.2.4 Timers, the "Offset" between the counter and timer should be >>> zero for a physical timer. This removes the offset to make the timer and >>> counter consistent. >>> >>> This also cleans up the physical timer implementation to better match >>> the virtual timer - both cval's now hold the hardware value. >>> >>> Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> >>> --- >>> xen/arch/arm/vtimer.c | 34 ++++++++++++++++++---------------- >>> xen/include/asm-arm/domain.h | 3 --- >>> 2 files changed, 18 insertions(+), 19 deletions(-) >>> >>> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c >>> index e6aebdac9e..21b98ec20a 100644 >>> --- a/xen/arch/arm/vtimer.c >>> +++ b/xen/arch/arm/vtimer.c >>> @@ -62,7 +62,6 @@ static void virt_timer_expired(void *data) >>> >>> int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config) >>> { >>> - d->arch.phys_timer_base.offset = NOW(); >>> d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0); >>> d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset - boot_count); >>> do_div(d->time_offset_seconds, 1000000000); >>> @@ -108,7 +107,6 @@ int vcpu_vtimer_init(struct vcpu *v) >>> >>> init_timer(&t->timer, phys_timer_expired, t, v->processor); >>> t->ctl = 0; >>> - t->cval = NOW(); >>> t->irq = d0 >>> ? timer_get_irq(TIMER_PHYS_NONSECURE_PPI) >>> : GUEST_TIMER_PHYS_NS_PPI; >>> @@ -167,6 +165,7 @@ void virt_timer_restore(struct vcpu *v) >>> static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool read) >>> { >>> struct vcpu *v = current; >>> + s_time_t expires; >>> >>> if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) >>> return false; >>> @@ -184,8 +183,9 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool read) >>> >>> if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) >>> { >>> - set_timer(&v->arch.phys_timer.timer, >>> - v->arch.phys_timer.cval + v->domain->arch.phys_timer_base.offset); >>> + expires = v->arch.phys_timer.cval > boot_count >>> + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; >>> + set_timer(&v->arch.phys_timer.timer, expires); >>> } >>> else >>> stop_timer(&v->arch.phys_timer.timer); >>> @@ -197,26 +197,27 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, >>> bool read) >>> { >>> struct vcpu *v = current; >>> - s_time_t now; >>> + uint64_t cntpct; >>> + s_time_t expires; >>> >>> if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) >>> return false; >>> >>> - now = NOW() - v->domain->arch.phys_timer_base.offset; >>> + cntpct = get_cycles(); >>> >>> if ( read ) >>> { >>> - *r = (uint32_t)(ns_to_ticks(v->arch.phys_timer.cval - now) & 0xffffffffull); >>> + *r = (uint32_t)((v->arch.phys_timer.cval - cntpct) & 0xffffffffull); >>> } >>> else >>> { >>> - v->arch.phys_timer.cval = now + ticks_to_ns(*r); >>> + v->arch.phys_timer.cval = cntpct + *r; >>> if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) >>> { >>> v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; >>> - set_timer(&v->arch.phys_timer.timer, >>> - v->arch.phys_timer.cval + >>> - v->domain->arch.phys_timer_base.offset); >>> + expires = v->arch.phys_timer.cval > boot_count >>> + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; >> >> You probably want a comment to explain why you set to 0 here. > > This code is repeated in 3 places - it probably doesn't make sense to have 3 > duplicate comments as well. I think it would fit well with your function > suggestion below. If you don't write a new helper, then the comment *must* be duplicated on every use. It is not pretty, but at least it avoids the reader to wonder why this is done. Similar, this should be explained in the commit message. > >>> + set_timer(&v->arch.phys_timer.timer, expires); >>> } >>> } >>> return true; >>> @@ -226,23 +227,24 @@ static bool vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r, >>> bool read) >>> { >>> struct vcpu *v = current; >>> + s_time_t expires; >>> >>> if ( !ACCESS_ALLOWED(regs, EL0PTEN) ) >>> return false; >>> >>> if ( read ) >>> { >>> - *r = ns_to_ticks(v->arch.phys_timer.cval); >>> + *r = v->arch.phys_timer.cval; >>> } >>> else >>> { >>> - v->arch.phys_timer.cval = ticks_to_ns(*r); >>> + v->arch.phys_timer.cval = *r; >>> if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) >>> { >>> v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; >>> - set_timer(&v->arch.phys_timer.timer, >>> - v->arch.phys_timer.cval + >>> - v->domain->arch.phys_timer_base.offset); >>> + expires = v->arch.phys_timer.cval > boot_count >>> + ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0; >> >> Same here. But I am wondering whether we could factor this code in a >> function. This would avoid code duplication and make the code simpler. >> >> This can be done as a follow-up as we may want to backport the fix. > > This is a great idea. However, I would consider this further scope creep for > this patch set - I think what is here is already a great improvement. I am > currently focused on wrapping up a project; unfortunately, this change would be > low on the priority list for me and I may not be able to get to it. While the code factoring is a cleanup, I don't view the lack of comment a great improvement. I quite like factoring, but I would not push it to be done in this series. However, I do care about code readability. It is not so hard to duplicate comments and you could have easily handle it when respining the series. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue 2019-12-11 21:13 [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements Jeff Kubascik 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset Jeff Kubascik @ 2019-12-11 21:13 ` Jeff Kubascik 2019-12-18 14:24 ` Julien Grall 2020-01-16 21:25 ` [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements Julien Grall 2 siblings, 1 reply; 12+ messages in thread From: Jeff Kubascik @ 2019-12-11 21:13 UTC (permalink / raw) To: xen-devel Cc: Stewart Hildebrand, Volodymyr Babchuk, Stefano Stabellini, Julien Grall Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4 specifies that the values in the TimerValue view of the timers are signed in standard two's complement form. When writing to the TimerValue register, it should be signed extended as described by the equation CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0] Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> --- xen/arch/arm/vtimer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c index 21b98ec20a..872181d9b6 100644 --- a/xen/arch/arm/vtimer.c +++ b/xen/arch/arm/vtimer.c @@ -211,7 +211,7 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, } else { - v->arch.phys_timer.cval = cntpct + *r; + v->arch.phys_timer.cval = cntpct + (uint64_t)(int32_t)*r; if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) { v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; -- 2.17.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue Jeff Kubascik @ 2019-12-18 14:24 ` Julien Grall 2020-01-17 21:29 ` Jeff Kubascik 0 siblings, 1 reply; 12+ messages in thread From: Julien Grall @ 2019-12-18 14:24 UTC (permalink / raw) To: Jeff Kubascik, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk Hi Jeff, On 11/12/2019 21:13, Jeff Kubascik wrote: > Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4 > specifies that the values in the TimerValue view of the timers are > signed in standard two's complement form. When writing to the TimerValue Do you mean CompareValue register instead of TimerValue register? > register, it should be signed extended as described by the equation > > CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0] This explains the signed part, but it does not explain why the 32-bit case. So I would mention that TimerValue is a 32-bit signed integer. Maybe saying "are 32-bit signed in standard ..." > > Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> > --- > xen/arch/arm/vtimer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c > index 21b98ec20a..872181d9b6 100644 > --- a/xen/arch/arm/vtimer.c > +++ b/xen/arch/arm/vtimer.c > @@ -211,7 +211,7 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, > } > else > { > - v->arch.phys_timer.cval = cntpct + *r; > + v->arch.phys_timer.cval = cntpct + (uint64_t)(int32_t)*r; > if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) > { > v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; > Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue 2019-12-18 14:24 ` Julien Grall @ 2020-01-17 21:29 ` Jeff Kubascik 2020-01-18 11:49 ` Julien Grall 0 siblings, 1 reply; 12+ messages in thread From: Jeff Kubascik @ 2020-01-17 21:29 UTC (permalink / raw) To: Julien Grall, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk On 12/18/2019 9:24 AM, Julien Grall wrote: > Hi Jeff, > > On 11/12/2019 21:13, Jeff Kubascik wrote: >> Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4 >> specifies that the values in the TimerValue view of the timers are >> signed in standard two's complement form. When writing to the TimerValue > > Do you mean CompareValue register instead of TimerValue register? I'm fairly certain TimerValue register is correct. When the guest writes to the TimerValue register, the equation below is used to convert it to a CompareValue equivalent. >> register, it should be signed extended as described by the equation >> >> CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0] > This explains the signed part, but it does not explain why the 32-bit > case. So I would mention that TimerValue is a 32-bit signed integer. > > Maybe saying "are 32-bit signed in standard ..." I pulled this equation directly from the ARMv8 Reference Manual - the manual goes into detail about the sign extension. This is referenced earlier in the commit message. >> >> Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com> >> --- >> xen/arch/arm/vtimer.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c >> index 21b98ec20a..872181d9b6 100644 >> --- a/xen/arch/arm/vtimer.c >> +++ b/xen/arch/arm/vtimer.c >> @@ -211,7 +211,7 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, >> } >> else >> { >> - v->arch.phys_timer.cval = cntpct + *r; >> + v->arch.phys_timer.cval = cntpct + (uint64_t)(int32_t)*r; >> if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE ) >> { >> v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING; >> > > Cheers, > > -- > Julien Grall > Sincerely, Jeff Kubascik _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue 2020-01-17 21:29 ` Jeff Kubascik @ 2020-01-18 11:49 ` Julien Grall 2020-01-21 14:43 ` Jeff Kubascik 0 siblings, 1 reply; 12+ messages in thread From: Julien Grall @ 2020-01-18 11:49 UTC (permalink / raw) To: Jeff Kubascik, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk On 17/01/2020 21:29, Jeff Kubascik wrote: > On 12/18/2019 9:24 AM, Julien Grall wrote: >> Hi Jeff, >> >> On 11/12/2019 21:13, Jeff Kubascik wrote: >>> Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4 >>> specifies that the values in the TimerValue view of the timers are >>> signed in standard two's complement form. When writing to the TimerValue >> >> Do you mean CompareValue register instead of TimerValue register? > > I'm fairly certain TimerValue register is correct. When the guest writes to the > TimerValue register, the equation below is used to convert it to a CompareValue > equivalent. I find the sentence quite confusing to read. It is not the write that needs to be signed extend, but the value used to compute CompareValue. So how about the following commit message: " xen/arm: Sign extend TimerValue when computing the CompareValue Xen will only store the CompareValue as it can be derived from the TimerValue (ARM DDI 0487E.a section D11.2.4): CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0] While the TimerValue is a 32-bit signed value, our implementation assumed it is a 32-bit unsigned value. " > >>> register, it should be signed extended as described by the equation >>> >>> CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0] >> This explains the signed part, but it does not explain why the 32-bit >> case. So I would mention that TimerValue is a 32-bit signed integer. >> >> Maybe saying "are 32-bit signed in standard ..." > > I pulled this equation directly from the ARMv8 Reference Manual - the manual > goes into detail about the sign extension. This is referenced earlier in the > commit message. While I agree the commit message explain in details the sign extension, there is nothing in your commit message about the size of TimerValue (i.e 32-bit). If you say it is a 32-bit signed value, then it is much clearer to understand the cast you added below. But please see above for a suggested commit message. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue 2020-01-18 11:49 ` Julien Grall @ 2020-01-21 14:43 ` Jeff Kubascik 0 siblings, 0 replies; 12+ messages in thread From: Jeff Kubascik @ 2020-01-21 14:43 UTC (permalink / raw) To: Julien Grall, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk On 1/18/2020 6:49 AM, Julien Grall wrote: > On 17/01/2020 21:29, Jeff Kubascik wrote: >> On 12/18/2019 9:24 AM, Julien Grall wrote: >>> Hi Jeff, >>> >>> On 11/12/2019 21:13, Jeff Kubascik wrote: >>>> Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4 >>>> specifies that the values in the TimerValue view of the timers are >>>> signed in standard two's complement form. When writing to the TimerValue >>> >>> Do you mean CompareValue register instead of TimerValue register? >> >> I'm fairly certain TimerValue register is correct. When the guest writes to the >> TimerValue register, the equation below is used to convert it to a CompareValue >> equivalent. > > I find the sentence quite confusing to read. It is not the write that > needs to be signed extend, but the value used to compute CompareValue. > So how about the following commit message: > > " > xen/arm: Sign extend TimerValue when computing the CompareValue > > Xen will only store the CompareValue as it can be derived from the > TimerValue (ARM DDI 0487E.a section D11.2.4): > > CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0] > > While the TimerValue is a 32-bit signed value, our implementation > assumed it is a 32-bit unsigned value. > " I agree with this version, it is clearer and and simpler. >> >>>> register, it should be signed extended as described by the equation >>>> >>>> CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0] >>> This explains the signed part, but it does not explain why the 32-bit >>> case. So I would mention that TimerValue is a 32-bit signed integer. >>> >>> Maybe saying "are 32-bit signed in standard ..." >> >> I pulled this equation directly from the ARMv8 Reference Manual - the manual >> goes into detail about the sign extension. This is referenced earlier in the >> commit message. > > While I agree the commit message explain in details the sign extension, > there is nothing in your commit message about the size of TimerValue > (i.e 32-bit). If you say it is a 32-bit signed value, then it is much > clearer to understand the cast you added below. > > But please see above for a suggested commit message. I'll send out an updated patch set with the new commit message. > Cheers, > > -- > Julien Grall > Sincerely, Jeff Kubascik _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements 2019-12-11 21:13 [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements Jeff Kubascik 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset Jeff Kubascik 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue Jeff Kubascik @ 2020-01-16 21:25 ` Julien Grall 2020-01-16 21:52 ` Jeff Kubascik 2 siblings, 1 reply; 12+ messages in thread From: Julien Grall @ 2020-01-16 21:25 UTC (permalink / raw) To: Jeff Kubascik, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk Hi Jeff, Do you plan to resend the series? If not, I am happy to respin the series for you. Best regards, On 11/12/2019 21:13, Jeff Kubascik wrote: > This patch set improves the emulation of the physical timer by removing the > physical timer offset and sign extend the TimerValue to better match the > behavior described in the ARMv8 Reference Manual (ARM DDI 0487E.a), section > D11.2.4. > > Changes in v2: > - Update commit message to specify reference manual version and section > - Change physical timer cval to hold hardware value > - Make sure to sign extend TimerValue on writes. This was done by first > casting the r pointer to (int32_t *), dereferencing it, then casting > to uint64_t. Please let me know if there is a more correct way to do > this > > Changes in v3: > - Split TimerValue sign extension fix into separate patch > - Update commit message to mention physical timer cleanup > - Removed physical timer cval initialization line > - Changed TimerValue sign extension to (uint64_t)(int32_t)*r > - Account for condition where cval < boot_count > > Jeff Kubascik (2): > xen/arm: remove physical timer offset > xen/arm: sign extend writes to TimerValue > > xen/arch/arm/vtimer.c | 34 ++++++++++++++++++---------------- > xen/include/asm-arm/domain.h | 3 --- > 2 files changed, 18 insertions(+), 19 deletions(-) > -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements 2020-01-16 21:25 ` [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements Julien Grall @ 2020-01-16 21:52 ` Jeff Kubascik 0 siblings, 0 replies; 12+ messages in thread From: Jeff Kubascik @ 2020-01-16 21:52 UTC (permalink / raw) To: Julien Grall, xen-devel Cc: Stewart Hildebrand, Stefano Stabellini, Volodymyr Babchuk Hello Julien, On 1/16/2020 4:25 PM, Julien Grall wrote: > Hi Jeff, > > Do you plan to resend the series? If not, I am happy to respin the > series for you. Feel free! Unfortunately, I currently don't have the bandwidth to keep this patch moving along. > Best regards, > > On 11/12/2019 21:13, Jeff Kubascik wrote: >> This patch set improves the emulation of the physical timer by removing the >> physical timer offset and sign extend the TimerValue to better match the >> behavior described in the ARMv8 Reference Manual (ARM DDI 0487E.a), section >> D11.2.4. >> >> Changes in v2: >> - Update commit message to specify reference manual version and section >> - Change physical timer cval to hold hardware value >> - Make sure to sign extend TimerValue on writes. This was done by first >> casting the r pointer to (int32_t *), dereferencing it, then casting >> to uint64_t. Please let me know if there is a more correct way to do >> this >> >> Changes in v3: >> - Split TimerValue sign extension fix into separate patch >> - Update commit message to mention physical timer cleanup >> - Removed physical timer cval initialization line >> - Changed TimerValue sign extension to (uint64_t)(int32_t)*r >> - Account for condition where cval < boot_count >> >> Jeff Kubascik (2): >> xen/arm: remove physical timer offset >> xen/arm: sign extend writes to TimerValue >> >> xen/arch/arm/vtimer.c | 34 ++++++++++++++++++---------------- >> xen/include/asm-arm/domain.h | 3 --- >> 2 files changed, 18 insertions(+), 19 deletions(-) >> > > -- > Julien Grall > Sincerely, Jeff Kubascik _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-01-23 12:28 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-11 21:13 [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements Jeff Kubascik 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset Jeff Kubascik 2019-12-18 14:20 ` Julien Grall 2020-01-17 21:24 ` Jeff Kubascik 2020-01-23 12:28 ` Julien Grall 2019-12-11 21:13 ` [Xen-devel] [PATCH v3 2/2] xen/arm: sign extend writes to TimerValue Jeff Kubascik 2019-12-18 14:24 ` Julien Grall 2020-01-17 21:29 ` Jeff Kubascik 2020-01-18 11:49 ` Julien Grall 2020-01-21 14:43 ` Jeff Kubascik 2020-01-16 21:25 ` [Xen-devel] [PATCH v3 0/2] xen/arm: physical timer improvements Julien Grall 2020-01-16 21:52 ` Jeff Kubascik
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.