On 20/03/20 01:18, Thomas Gleixner wrote: >> No, it is possible to do that depending on the clock setup on the live >> migration source. You could cause the warning anyway by setting the >> clock to a very high (signed) value so that kernel_ns + kvmclock_offset >> overflows. > > If that overflow happens, then the original and the new host have an > uptime difference in the range of >200 hundreds of years. Very realistic > scenario... > > Of course this can happen if you feed crap into the interface, but do > you really think that forwarding all crap to a guest is the right thing > to do? > > As we all know the hypervisor orchestration stuff is perfect and would > never feed crap into the kernel which happily proliferates that crap to > the guest... But the point is, is there a sensible way to detect it? Only allowing >= -2^62 and < 2^62 or something like that is an ad hoc fix for a warning that probably will never trigger outside fuzzing. I would expect that passing the wrong sign is a more likely mistake than being off by 2^63. This data is available everywhere between strace, kernel tracepoints and QEMU tracepoints or guest checkpoint (live migration) data. I just don't see much advantage in keeping the warning. Paolo
