At Mon, 24 Jun 2024 09:29:44 +0200, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote: Subject: Re: Xen timecounter issues > > On Sun, Jun 23, 2024 at 01:58:36PM +0000, Taylor R Campbell wrote: > > 1. Is there an array of the following variables? > > > > - dom0 kernel (netbsd-8, netbsd-9, netbsd-10, linux, freebsd, ...) I think the dom0 kernel is irrelevant for the domU time skew I've observed, but in any case my dom0s have been running primarily an ancient -current (9.99.81). > > - domU kernel, if misbehaviour observed in domU (ditto) Seen in NetBSD only, from 9.99.81, 9.99.81 with xen_clock.c:1.18, through to 10.0. > > - Xen kernel version Since 4.18 for me. 4.11 was A-OK. Rumours are 4.15 has problems, but I never ran it. > > - virtualization type (pv/pvh/hvm/...) PV. > > - Xen TSC configuration I've used both tsc_mode=0 and tsc_mode=always_emulate in my domUs, but on my hardware I think they should be equivalent. I did a quick test of tsc_mode=native but on my hardware it immediately behaved badly, as expected, so I stopped it. > > - physical CPU (and, whether the physical CPU has invariant TSC) Xeon E5440 and X5460, neither of which have the invariant bit (nor the constant bit). I have another machine with Xeon E5645 cores, also without invariant, but it does not exhibit problems. The NetBSD domUs running there do report some different interesting events, but even after months of uptime they keep accurate time. vcpu0 raw systime went backwards 1709 0 intr vcpu0 missed hardclock 131 0 intr > > - misbehaviour summary After about 7.5 days all NetBSD domUs start to experience time drift that ntpd cannot compensate for, and it can quickly get extreme. > AFAIK no. From what I understood the misbehavior is only seen in dom0. The misbehaviour I've been primarily concerned with, i.e. time-skew that ntpd can't correct for, only happens in domU. I did observe dom0 having problems without dom0_vcpus_pin=true on my older hardware, but that was only a brief test. As soon as I pinned the vCPUs, even at runtime, the problems disappeared. > > (c) Can a domain be migrated from a host with one Xen TSC > > configuration to a host with a different Xen TSC configuration? Yes, definitely. E.g. see this comment in xen/arch/x86/time.c: /* * This may be called as many as three times for a domain, once when the * hypervisor creates the domain, once when the toolstack creates the * domain and, if restoring/migrating, once when saved/migrated values * are restored. Care must be taken that, if multiple calls occur, * only the last "sticks" and all are completed before the guest executes * an rdtsc instruction */ int tsc_set_info( -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpI6Qhkj_v7b.pgp
Description: OpenPGP Digital Signature