On Tue, Apr 26 2022 at 09:51, Adrian Hunter wrote: > On 25/04/22 20:05, Thomas Gleixner wrote: >> On Mon, Apr 25 2022 at 16:15, Adrian Hunter wrote: >>> On 25/04/22 12:32, Thomas Gleixner wrote: >>>> It's hillarious, that we still cling to this pvclock abomination, while >>>> we happily expose TSC deadline timer to the guest. TSC virt scaling was >>>> implemented in hardware for a reason. >>> >>> So you are talking about changing VMX TCS Offset on every VM-Entry to try to hide >>> the time jumps when the VM is scheduled out? Or neglect that and just let the time >>> jumps happen? >>> >>> If changing VMX TCS Offset, how can TSC be kept consistent between each VCPU i.e. >>> wouldn't that mean each VCPU has to have the same VMX TSC Offset? >> >> Obviously so. That's the only thing which makes sense, no? > > [ Sending this again, because I notice I messed up the email "From" ] > > But wouldn't that mean changing all the VCPUs VMX TSC Offset at the same time, > which means when none are currently executing? How could that be done? Why would you change TSC offset after the point where a VM is started and why would it be different per vCPU? Time is global and time moves on when a vCPU is scheduled out. Anything else is bonkers, really. If the hypervisor tries to screw with that then how does the guest do timekeeping in a consistent way? CLOCK_REALTIME = CLOCK_MONOTONIC + offset That offset changes when something sets the clock, i.e. clock_settime(), settimeofday() or adjtimex() in case that NTP cannot compensate or for the beloved leap seconds adjustment. At any other time the offset is constant. CLOCK_MONOTONIC is derived from the underlying clocksource which is expected to increment with constant frequency and that has to be consistent accross _all_ vCPUs of a particular VM. So how would a hypervisor 'hide' scheduled out time w/o screwing up timekeeping completely? The guest TSC which is based on the host TSC is: guestTSC = offset + hostTSC * factor; If you make offset different between guest vCPUs then timekeeping in the guest is screwed. The whole point of that paravirt clock was to handle migration between hosts which did not have the VMCS TSC scaling/offset mechanism. The CPUs which did not have that went EOL at least 10 years ago. So what are you concerned about? Thanks, tglx _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization