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

[Gleb Natapov <gleb@redhat.com>]

On Wed, Dec 12, 2012 at 12:46:41AM -0700, Matthew Ogilvie wrote:
> 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? 
No, all io is handled either by KVM or qemu.

>                                        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?
> 
They are common because they work on device state that can comes from
either QEMU device emulation or kvm device emulation. Why QEMU even touches
KVM's device state other than for migration I do not know. Jan?

I see that your patch 10 changes pit_get_next_transition_time() and
pit_get_out(). If the result of those functions will be different on
patched and un-patched kernels it may indeed be a problem, but if
kernels are different only in logic and the sate is the same then it
should not be different from patched and un-patched QEMU case.

> > 
> > >      * 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.
> 
Will look.

--
			Gleb.