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

libxl uses wall clock to wait for backend devices


  • To: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Olaf Hering <olaf@xxxxxxxxx>
  • Date: Tue, 27 Apr 2021 12:47:08 +0200
  • Arc-authentication-results: i=1; strato.com; dkim=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1619520437; s=strato-dkim-0002; d=strato.com; h=Message-ID:Subject:To:From:Date:Cc:Date:From:Subject:Sender; bh=Skn0ST4l/hyJtjamObmZL1MnfQrrqMO44BlAGZPozRU=; b=Vr7LvFy3LXJd2B5vAHgN7Qu/Q87PA4/dV0X462NgU7e04hgxdaIduWlftmbMZcJG8x TbTLBWN7LOcUMn9UKmoKUnGekUTB8lYrkq6gz7xcu9uOopU3w4yb2dY4zYV+jLFxZnwr +hBlDa6gT+nlt+1vYTzCllEbBU53PK0p7nadtvK4N0w9bYIWTUWT6e9hpI/VkWcbBmhT PtAZnvy76eA8hDtKYXR7pjSJ0dAAdqgjZwjM/PsBQphwTuPITK22fiGIiSv/b5HkNSzB y5SWDmhNUNDoABprC8Itq4L/pTB713vaiTtEcrDh+5TeL/s4dHzzjwkNdKgHeZufvFre Yx0g==
  • Arc-seal: i=1; a=rsa-sha256; t=1619520437; cv=none; d=strato.com; s=strato-dkim-0002; b=Ki1Z7R1d0kzo95iq0M9E0a2tRSm9iXPqGzMNTMNh+LODZlhwdntXg0J74Ui7CGNQ+M chyVC+sNixSWbAUceTHZVqCsCtBxBmvlJSHAgJlGDyHhHjxN7SVwlHhRUMGQ/xpz2bFU TO59ebrnwh/sMoGfkcHwS6jksI0eD7dLSBiFaADSZqFOebaaEFs1KMjfctEC6Oz6Yip5 yWYZjQK2u7x6C5KV0I4k2j1HpbzCLpmD2f8qybGhDeRhSxk9rBE/tB8m9kgnZ8QDTevz EKqGTJuxjtryCBndOIJXTkdMSoKZ599N+9GzNHobpgiroZf3ljwvDife1umB2CLnySUS kUkA==
  • Authentication-results: strato.com; dkim=none
  • Delivery-date: Tue, 27 Apr 2021 10:47:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Does anyone happen to know why libxl__wait_device_connection (via 
libxl__ev_time_register_rel) uses absolute time values, instead of relative 
monotonic times, to wait for the expected state changes?

I think this can easily confuse libxl when the system time is corrected by some 
ntp daemon while libxl is launching domUs.


Olaf

Attachment: pgpcyPLyauWw_.pgp
Description: Digitale Signatur von OpenPGP


 


Rackspace

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