[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



CC'ing Julien's new email address

On Thursday, November 14, 2019 2:33 PM, Jeff Kubascik 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.