Re: [Qemu-devel] [PATCH v7 00/10] i8254, i8259 and running Microport UNIX (ca 1987)

[Matthew Ogilvie]

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...
>