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);
/* ... */
/*
* Program the next event in oneshot mode
*
* Delta is given in PIT ticks
*/
static int pit_next_event(unsigned long delta, struct
clock_event_device *evt)
{
raw_spin_lock(&i8253_lock);
outb_p(delta & 0xff , PIT_CH0); /* LSB */
outb_p(delta >> 8 , PIT_CH0); /* MSB */
raw_spin_unlock(&i8253_lock);
return 0;
}
/* ... */
#endif
> 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.
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
