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

[Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>]

On Mon, Dec 10, 2012 at 10:47:59AM -0600, Anthony Liguori wrote:
> Jan Kiszka <jan.kiszka@web.de> writes:
> 
> > On 2012-12-10 06:14, Matthew Ogilvie wrote:
> >> On Sun, Nov 25, 2012 at 02:51:36PM -0700, Matthew Ogilvie wrote:
> >>> This series makes a series of mostly-unrelated fixes to allow
> >>> running an old Microport UNIX (ca 1987) guest under qemu.
> >>>
> >>> Changes since version 6:
> >>>    * Patches 1 through 6 haven't changed, other than resolving
> >>>      a couple of simple conflicts.
> >>>    * Patch 7 "fixes" IRQ0 by just making it work like before,
> >>>      rather than fixing it properly.  This avoids possible risk
> >>>      to cross-version migration, etc.
> >>>    * Patches 8, 9, and 10 provide one possible gradual transition path
> >>>      to properly fix the 8254 model with relatively little risk to
> >>>      migration/etc.  The idea is that 8 and 9 could be applied
> >>>      immediately in preparation for a future fix, and then the
> >>>      actual fix (10) could be applied sometime in the future when
> >>>      migrating to or from pre-patch-9 versions is no longer a concern.
> >>>         I am not actually aware of ANY guest that actually needs
> >>>      an improved 8254 model, but this provides one way to improve
> >>>      it if desired.
> >>>
> >> 
> >> Ping?
> >> 
> >> What would it take to get some variation of this series
> >> into 1.4?  The last feedback I've seen was against version 5, back
> >> in September.
> >> http://search.gmane.org/?query=ogilvie&group=gmane.comp.emulators.qemu
> >
> > I suppose it's primarily a question of time for some reviewer(s). Sorry,
> > I wasn't able to look at it yet, maybe I will have a chance next week.
> 
> If you added a test case for the i8254 using the mc146818rtc qtest test
> case as an example, you would very likely attract more reviewers.
> 
> It would also make it easier to ensure that the issues you're fixing
> here don't regress in the future too.
> 
> Regards,
> 
> Anthony Liguori

I'll look into adding some qtest test case(s), starting along the same
lines as the i8259 "kvm-unit-tests" case I posted Sep 9, 2012, (and the
standalone test it was based on).  See also
http://home.comcast.net/~mmogilvi/downloads/i8259-imr-test-2012-09-02.tar.bz2

Note that for the i8259/i8254 stuff, strictly speaking
I only really need a fix to the trailing-edge handling of the
cascade (IRQ2) line of the i8259.  A more general fix (all IRQ lines)
might be nice, but such a general fix (especially IRQ0) exposes
bugs in the i8254 model.  And fixing that poses at least a
small risk to cross-version guest migration.

All of which raises the strategic question of how much scope creap of
fixing/changing low level device models should I worry about, to
address a problem only seen in a very rare guest?  Vs some kind
of narrower, non-general fix (IRQ2 only, or all-except-IRQ0, or
something else).

Also, there is a CGA compatibility hack I need.  As well as
three trivial patches that I don't actually need, but seem
like easy fixes.

> 
> >
> >> 
> >>> ----------------
> >>> Split up this series?
> >>>
> >>> I'm not sure what the next steps are to get these into qemu, other
> >>> than waiting for 1.4 for at least the non-trivial parts?
> >>>
> >>> Patches 1 through 3 could be considered independent trivial patches.
> >>> Would splitting them apart improve the changes of getting them into qemu?
> >>>
> >>> Patch 4 isn't quite trivial, but it is well isolated (other than
> >>> small documentation conflicts against patch 3).  Should it be split
> >>> off?  It hasn't changed since version 3, but nobody has really
> >>> commented on it.
> >>>
> >>> Patches 5 through 10 are interrelated, and should remain related in
> >>> a series.
> >>>
> >>> ----------------
> >>> 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:
> >>>      * Or more involved fixes would involve new ioctl()'s and
> >>>        command line arguments to select old or fixed 8254 models
> >>>        dynamically.  See below.
> >> 
> >> Any preferences?
> >
> > As Avi left, I'm putting Gleb and Marcelo on CC.
> >
> >> 
> >>>
> >>> ----------------
> >>> 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.
> >> 
> >> Or:
> >> 1.1. Don't fix any 8259 lines either, except for the one line (IRQ2) that
> >>      is giving me trouble.  (Recall that the original problem is the guest
> >>      masking off IRQ14 in the 8259, and the resulting IRQ2 trailing edge
> >>      isn't handled correctly in the master 8259, resulting in a
> >>      spurious interrupt.)
> >> 
> >>>
> >>> 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?)
> >>>
> >>> 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...
> >>>
> >>> ----------------
> >>>
> >>> Matthew Ogilvie (10):
> >>>   fix some debug printf format strings
> >>>   vl: fix -hdachs/-hda argument order parsing issues
> >>>   qemu-options.hx: mention retrace= VGA option
> >>>   vga: add some optional CGA compatibility hacks
> >>>   i8259: fix so that dropping IRQ level always clears the interrupt
> >>>     request
> >>>   i8259: refactor pic_set_irq level logic
> >>>   i8254/i8259: workaround to make IRQ0 work like before
> >>>   i8254: add comments about fixing timings
> >>>   i8254: prepare for migration compatibility with future fixes
> >>>   FOR FUTURE: fix i8254/i8259 IRQ0 line logic
> >
> > Jan