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

[Gleb Natapov]

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

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

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

> 
> ----------------
> 
> 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
> 
>  hw/cirrus_vga.c   |  4 ++--
>  hw/i8254.c        | 24 +++++++++++++++++++--
>  hw/i8254_common.c | 18 ++++++----------
>  hw/i8259.c        | 28 ++++++++++---------------
>  hw/ide/cmd646.c   |  5 +++--
>  hw/ide/via.c      |  5 +++--
>  hw/pc.h           |  4 ++++
>  hw/vga.c          | 37 ++++++++++++++++++++++++++-------
>  qemu-options.hx   | 27 +++++++++++++++++++++++-
>  vl.c              | 62 
> ++++++++++++++++++++++++++++++++++++-------------------
>  10 files changed, 147 insertions(+), 67 deletions(-)
> 
> -- 
> 1.7.10.2.484.gcd07cc5
> 

--
                        Gleb.