src/sys/dev/xen/timer/timer.c, branch releng/12.2

Make timespecadd(3) and friends public

2018-07-30T15:46:40Z

The timespecadd(3) family of macros were imported from NetBSD back in r35029. However, they were initially guarded by #ifdef _KERNEL. In the meantime, we have grown at least 28 syscalls that use timespecs in some way, leading many programs both inside and outside of the base system to redefine those macros. It's better just to make the definitions public. Our kernel currently defines two-argument versions of timespecadd and timespecsub. NetBSD, OpenBSD, and FreeDesktop.org's libbsd, however, define three-argument versions. Solaris also defines a three-argument version, but only in its kernel. This revision changes our definition to match the common three-argument version. Bump _FreeBSD_version due to the breaking KPI change. Discussed with: cem, jilles, ian, bde Differential Revision: https://reviews.freebsd.org/D14725

sys/dev: further adoption of SPDX licensing ID tags.

2017-11-27T14:52:40Z

Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.

Stop calling atrtc_set() from the xen timer clock_settime() method. That

2017-08-11T19:02:11Z

removes the only reference to atrtc_set() from outside of atrtc.c, so make it static. The xen timer driver registers as a realtime clock with 1us resolution. In the past that resulted in only the xen timer's clock_settime() getting called, so it would call atrtc_set() to set the hardware clock as well. As of r32090, the clock_settime() method of all registered realtime clocks gets called, so the xen driver no longer needs to chain-call the lower-resolution driver. Thanks to royger@ for talking me through the xen stuff, and for testing.

xen/timer: mark the Xen PV timer as not safe for suspension

2017-02-22T09:22:17Z

Note that the timer itself fully supports suspension, but due to the lack of ordering during the resume process FreeBSD cannot guarantee that the timer is resumed before any device attempts to use it. Submitted by: Liuyingdong Reviewed by: royger Differential Revision: https://reviews.freebsd.org/D9639

xen/timer: re-introduce the inittodr call in the resume path

2016-06-09T16:15:01Z

r298930 removed the inittodr call, but it seems like this prevents "calcru: runtime went backwards ..." messages from occasionally appearing when resuming from migration. Reported by: Karl Pielorz Sponsored by: Citrix Systems R&D

xen/pvclock: set the correct resolution for the Xen PV clock

2016-05-04T13:49:59Z

The Xen PV clock has a resolution of 1ns, so set the resolution to the highest one that FreeBSD supports, which is 1us. MFC after: 2 weeks Sponsored by: Citrix Systems R&D

xen/time: fix PV clock resolution

2016-05-02T16:16:08Z

The current resolution of the Xen PV clock is too high, which causes an adjustment of 5s to be applied to it. Reduce the resolution to be the same as the RTC plus one, so it's always selected as the best source when available on x86. Also don't reset the clock on resume, it's pointless and discards any previous adjustments. Sponsoted by: Citrix Systems R&D

xen/time: allow Dom0 to set the host time

2016-05-02T16:15:28Z

Dom0 should be able to set the host time. This is implemented by first writing to the RTC (as would be done on bare metal), and then using the XENPF_settime64 hypercall in order to force Xen to update the wallclock shared page of all domains. Sponsored by: Citrix Systems R&D

xen/timer: remove the timer setup loop

2016-05-02T16:13:55Z

With the removal of the usage of the VCPU_SSHOTTMR_future flag, now all errors from xentimer_vcpu_start_timer should be considered fatal, and the loop is no longer needed since in case of setting the timer in the past we will get an event interrupt right away (instead of returning ETIME). Sponsored by: Citrix Systems R&D MFC after : 2 weeks

xen/x86: don't lose event interrupts

2016-05-02T16:13:11Z

On slow platforms with unreliable TSC, such as QEMU emulated machines, it is possible for the FreeBSD kernel to request the next event in the past. In that case, in the current implementation of xentimer_vcpu_start_timer, we simply return -ETIME. To be precise Xen returns -ETIME and we pass it on. As a consequence we need to loop around to function to make sure that the timer is properly set. Instead it is better to always ask the hypervisor for a timer event, even if the timeout is past. To do that, remove the VCPU_SSHOTTMR_future flag. Submitted by: Stefano Stabellini Reviewed by: royger MFC after: 2 weeks