ACK: [b:azure-4.15,f:azure][PATCH 0/2] Keep Chrony time in sync

[Kleber Souza]

On 16.12.20 01:12, Kelsey Skunberg wrote:
> BugLink: https://bugs.launchpad.net/bugs/1896784
> 
> SRU Justification:
> 
> [Impact]
> 
> Microsoft would like to request a change to the time keeping method in
> the Azure images.
> 
> We would like to request that an Azure image uses the Azure host for
> time sync by default.  This will require the use of the Chrony package.
> 
> The Chrony package would need to be installed by default in all images
> and be configured to use /dev/ptp0 for timekeeping.
> 
> There is a request for two patches to be backported so Chrony time can
> stay in sync before being set as the default.
> 
> Patches are already in the 5.8 kernel. Only needed for azure 5.4 and
> 4.15
> 
> 
> [Fix]
> 
> backport these two patches:
> b46b4a8a57c3 ("hv_utils: drain the timesync packets on onchannelcallback")
> 90b125f4cd26 ("hv_utils: return error if host timesysnc update is stale")
> 
> [Test Case]
> 
> Desired test cases:
>   - verify Chrony time can stay in sync
>   - verify caller is notified if host timesync update is stale
>   - verify all timesync packets are drained on onchannelcallback to avoid
>     stale packets
> 
> Microsoft holds test cases for the above. They verified a 4.15 and 5.4
> test kernels with the above patches backported to work as expected.
> 
> [Regression Potential]
> 
> Caller may get an error now if host timesync messages were not processed
> by the guest. This wasn't getting reported to the caller before and may
> appear to be a regression if it occurs.
> 
> Regression potential may also lay in still incorrectly managing timesync
> packets on onchannelcallback.
> 
> Vineeth Pillai (2):
>    hv_utils: return error if host timesysnc update is stale
>    hv_utils: drain the timesync packets on onchannelcallback
> 
>   drivers/hv/hv_util.c | 64 ++++++++++++++++++++++++++++++++++----------
>   1 file changed, 50 insertions(+), 14 deletions(-)
> 

The backports look good to me.

Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>