On 16.07.24 14:32, David Woodhouse wrote:
> On 16 July 2024 12:54:52 BST, Peter Hilber
> wrote:
>> On 11.07.24 09:50, David Woodhouse wrote:
>>> On Thu, 2024-07-11 at 09:25 +0200, Peter Hilber wrote:
IMHO this phrasing is better, since it directly refers to the state of the
On 08.07.24 11:27, David Woodhouse wrote:
> +
> + /*
> + * Time according to time_type field above.
> + */
> + uint64_t time_sec; /* Seconds since time_type epoch */
> + uint64_t time_frac_sec; /* (seconds >> 64) */
> + uint64_t time_esterror_picosec;
On 11.07.24 09:50, David Woodhouse wrote:
> On Thu, 2024-07-11 at 09:25 +0200, Peter Hilber wrote:
>>
>> IMHO this phrasing is better, since it directly refers to the state of the
>> structure.
>
> Thanks. I'll update it.
>
>> AFAIU if there would be abnormal delays in store buffers, causing
On 10.07.24 18:01, David Woodhouse wrote:
> On Wed, 2024-07-10 at 15:07 +0200, Peter Hilber wrote:
>> On 08.07.24 11:27, David Woodhouse wrote:
>>> From: David Woodhouse
>>>
>>> The vmclock "device" provides a shared memory region with precision clock
>>> information. By using shared memory, it
On 08.07.24 11:27, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based cross timestamps into
>
