On Tue, Dec 11, 2012 at 11:20:05AM +0000, Jamie Lokier wrote:
> Matthew Ogilvie wrote:
> > 2. Just fix it immediately, and don't worry about migration. Squash
> > the last few patches together. A single missed periodic
> > timer tick that only happens when migrating
> > between versions of qemu is probably not a significant
> > concern. (Unless someone knows of an OS that actually runs
> > the i8254 in single shot mode 4, where a missed interrupt
> > could cause a hang or something?)
>
> Hi Matthew,
>
> Such as Linux? 0x38 looks like mode 4 to me. I suspect it's used in
> tickless mode when there isn't a better clock event source.
>
> linux/drivers/clocksource/i8253.c:
>
> #ifdef CONFIG_CLKEVT_I8253
> /* ... */
>
> case CLOCK_EVT_MODE_ONESHOT:
> /* One shot setup */
> outb_p(0x38, PIT_MODE);
>
> /* ... */
I'm not very familiar with how Linux selects and uses timers, but
I think the full qemu fix will only lose a mode 4 interrupt during
migration if several conditions are all met:
1. Guest's kernel is configured to be tickless.
2. Guest's kernel is using the 8254, and not something better
like the HPET. (Perhaps the better device is configured out
of the kernel, and/or explicitly left out of qemu's list of
devices. Both of which I would expect to be rare.)
3. The user is migrating from a newer/fixed version of qemu, back
to an older version of qemu. (Not sure how common this is. It
may be common in some kind of cluster environment where you
take down one real machine at a time for upgrades and one
of the upgraded machines needs to be taken back down, or if you
migrate between completely different data centers that are on
different upgrade cyles, or something.)
If any of these three conditions is NOT met, then I don't expect it
to be possible to lose an interrupt in mode 4. Perhaps the combination
can be considered rare enough not to worry about?
It may generate a immediate interrupt (instead of delayed
properly) if the guest resets the one-shot mode due to some
other device's interrupt (fixed normal high vs old normal low),
but hopefully the guest won't be bothered too much by a single
such interrupt.
Also, for guests that use periodic modes (2 or 3), it is still possible
it might gain or lose 1 periodic timer interrupt during migration
between versions of qemu, but that probably isn't a big deal.
NOTE: I'm assumming that the HPET qemu model doesn't have similar trailing
edge or off-by-one-tick problems as the 8254 model. Nor any other
device, for that matter.
If such breakage is considered minor enough and/or rare enough, then
I certainly think the simplicity of this option is attractive.
>
> > 4. Support both old and fixed i8254 models, selectable at runtime
> > with a command line option. (Question: What should such an
> > option look like?) This may be the best way to actually
> > change the 8254, but I'm not sure changes are even needed.
> > It's certainly getting rather far afield from running Microport
> > UNIX...
>
> I can't see a reason to have the old behaviour, if every guest works
> with the new one, except for this awkward cross-version migration
> thing.
Yes, the only reason to even consider having both old and new behavior
around is if the migration thing is considered significant enough to
warrant it.
One argument for making it configurable is if the user has an environment
where you expect to occasionally migrate back to old versions, then you
might want to start with the old model even if you initially boot
the guest on a new version qemu.
>
> I guess ideally, device emulations would be versioned when their
> behaviour changes, rather like shared libraries are, and the
> appropriate old version kept around to be loaded for a particular
> machine that's still running with it. Sounds a bit complicated though.
>
> Best,
> -- Jamie
