All of lore.kernel.org
 help / color / mirror / Atom feed
* [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

* [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 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 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 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

* 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 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 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

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.