On Friday 27 October 2006 12:09, Zachary Amsden wrote: > Andi Kleen wrote: > > On Thu, Oct 19, 2006 at 05:09:22PM -0700, Zachary Amsden wrote: > >> Add a way to disable the timer IRQ routing check via a boot option. The > >> VMI timer code uses this to avoid triggering the pester Mingo code, > >> which probes for some very unusual and broken motherboard routings. It > >> fires 100% of the time when using a paravirtual delay mechanism instead > >> of using a realtime delay, since there is no elapsed real time, and the > >> 4 timer IRQs have not yet been delivered. > > > > You mean paravirtualized udelay will not actually wait? > > Yes, but even putting that problem aside, the timing element here is > tricky to get right in a VM. > > > This implies that you can't ever use any real timer in that kind of > > guest, right? > > No. You can use a real timer just fine. But there is no reason ever to > use udelay to busy wait for "hardware" in a virtual machine. Drivers > which are used for real hardware may turn udelay back on selectively; > but this is another patch. > > >> In addition, it is entirely possible, though improbable, that this bug > >> could surface on real hardware which picks a particularly bad time to > >> enter SMM mode, causing a long latency during one of the timer IRQs. > > > > We already have a no timer check option. But: > > Really? I didn't see one that disabled the broken motherboard detection > / workaround code, which is what we are trying to avoid here. no_timer_check. But it's only there on x86-64 in mainline - although there were some patches to add it to i386 too. > That is what this patch is building towards, but the boot option is > "free", so why not? In the meantime, it helps non-paravirt kernels > booted in a VM. Hmm, you meant they paniced before? If they just fail a few tests that is not particularly worrying (real hardware does that often too) -Andi
