[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
|