On Monday, January 20, 2020 1:42 PM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > Simply because all of this is horribly fragile and if you put virt into > the picture it gets even worse. > > The initial calibration via PIT/HPET is halfways accurate in most cases > and we use the 1% as a sanity check. > > > Ideally it would be better to get the early calibration right than > > risk getting it wrong because of an "anomaly". > > Ideally we would just have a way to read the stupid frequency from some > reliable place, but there is no such thing. > > Guess why we have all this code, surely not because we have nothing > better to do than dreaming up a variety of weird ways to figure out that > frequency. Thank you for the explanation. > Widening the error window here is clearly a hack. As you have to supply > a valid number there, then why not just providing the frequency itself > on the command line? That would at least make most sense and would avoid > to use completely wrong data in the early boot stage. That sounds good. I'll assume that the user will be supposed to provide a flag tsc_early_hz= so that refine_calibration_work can get better numbers while still doing the 1% sanity check. I'll send a patch this week.
