Re: [Xen-devel] arm/vtimer: Physical timer emulation and the physical counter

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

Adding,
Artem as this is potentially of interest to the FuSa group?
Lars 

> On 14 Nov 2019, at 13:33, Jeff Kubascik <Jeff.Kubascik@xxxxxxxxxxxxxxx> wrote:
> 
> Hello,
> 
> I'm working on a port of a RTOS (RTEMS) to Xen on ARM, and came across an
> interesting finding in how Xen emulates the physical timer on ARM.
> 
> In testing different configurations of the port, I have the RTOS configured to
> use the ARM generic physical timer. The driver operates the physical timer in
> the "CompareView" mode, where the timer condition is met when the physical
> counter reaches the programmed CompareValue.
> 
> The driver initializes the physical timer by first reading the physical 
> counter
> register CNTPCT, adding the systick interval, and then writing the result to 
> the
> CompareValue register CNTP_CVAL. This appears to be valid behavior based on my
> understanding of the ARMV8 Architecture Reference Manual, since the physical
> timer "offset" is specified to be zero.
> 
> Xen will trap accesses to the physical timer registers - CNTP_CTL, CNTP_CVAL,
> and CNTP_TVAL, which happens in xen/arch/arm/vtimer.c. Xen will add or remove 
> an
> offset phys_timer_base.offset when reading or writing to the 
> CNTP_CVAL/CNTP_TVAL
> registers. This offset is determined when the vtimer is initialized on guest
> creation.
> 
> However, Xen does not trap access to the physical counter register CNTPCT. 
> This
> means the guest has direct access to the register. It also means the offset is
> not applied here. I believe this is a problem, because the physical timer is 
> no
> longer consistent with the physical counter from the guest's perspective - 
> there
> is a non-zero, unknown offset between the two.
> 
> This was a problem for the RTOS, since it was reading the physical counter
> register (Xen does not apply an offset), adding some interval, and then 
> setting
> the CompareValue register (Xen applies the offset), resulting in a long delay
> before the timer expires.
> 
> I was able to fix this by adding code in Xen to trap access to CNTPCT and
> applying the offset - I can submit the patch if there is interest. However, I
> was curious if there was an reason for not trapping/ emulating access to the
> physical counter register and applying the offset?
> 
> Sincerely,
> Jeff Kubascik
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel