On Tue, Dec 11, 2012 at 06:19:56PM +0200, Gleb Natapov wrote: > On Sun, Nov 25, 2012 at 02:51:36PM -0700, Matthew Ogilvie wrote: > > ---------------- > > Still needed: > > > > * Corresponding KVM patches. The best approach may depend > > on what option is selected for qemu above. > > * Note that KVM uses a simplified model that doesn't try > > to emulate the trailing edge of the interrupt very well > > at all. I'm not proposing to change this aspect of it. > > * A patch analogous to 7 should be easy. > > * Patches 8 through 10 are also fairly easy by themselves. > > But now we start having an explosion of combinations > > of versions of KVM and qemu and migration to/from, and it > > might be better to: > Why explosion of combinations? I do not see any changes in > migration code in your series, so as long as we care about migration > from in-kernel irqchip to in-kernel irqchip we should be independent > from qemu version, no?
You may be correct. I'm a little hazy on the details of how things are split between KVM and QEMU. Are there situations that do ioport read/write handling within qemu rather than KVM? How about things like pit_get_out(), pit_get_next_transition_time(), etc in qemu/hw/i8254_common.c? (If not used when KVM is enabled, then why are they "common"?) What are the implications if qemu and KVM implementations of such functions disagree? > > > * Or more involved fixes would involve new ioctl()'s and > > command line arguments to select old or fixed 8254 models > > dynamically. See below. > > > > ---------------- > > Alternative options for improving the i8254 model and migration: > > > > 1. Don't fix 8254 at all. Just apply through patch 7 or 8, and don't try > > to make any additional fixes. I don't know of any guests that need > > improvements, so this could be a viable option. > > > > 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?) > > > If migration can fail only with the single, rarely (if ever) used mode, > I honestly like this option the most. As long as it is truly rare, I agree. I'm just not sure if the "rare" qualification is actually true or not. See also my response to Jamie Lokier about Linux's tickless configuration. > > > 3. Use patches 8 and 9 now, and patch 10 sometime in the future. > > If it was just qemu, this would be attractive. But when you > > also need to worry about a bunch of combinations of versions of > > qemu and KVM and migration, this is looking less 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... > If we will start doing it for each bug... >
