On Mon, 2024-07-29 at 11:33 -0400, Michael S. Tsirkin wrote:
> you said you will use __le here?
I hadn't intended to bother until we add the virtio discovery and
negotiation paths; it would basically be cosmetic for now.
Although I *will* do so with the QEMU side before posting the latest
version
On Mon, Jul 29, 2024 at 11:42:22AM +0100, David Woodhouse wrote:
> +struct vmclock_abi {
> + /* CONSTANT FIELDS */
> + uint32_t magic;
> +#define VMCLOCK_MAGIC0x4b4c4356 /* "VCLK" */
> + uint32_t size; /* Size of region containing this structure */
> + uint16_t vers
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
KVM clock values. Unlike the KVM PTP clock, it does so o
On Sat, Jul 06, 2024 at 04:14:39PM +0100, 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 c
On Mon, 2024-07-08 at 10:17 +0100, Simon Horman wrote:
> Hi David,
>
> As per my comment on v2, although it is harmless in this case,
> it would be nicer to use strscpy() here and avoid fortification
> warnings.
>
Oh, pants! I have fixed that; must have sent the wrong version.
V4 coming up short
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
KVM clock values. Unlike the KVM PTP clock, it does so o
