[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v7 00/10] i8254, i8259 and running Microport UNI
From: |
Gleb Natapov |
Subject: |
Re: [Qemu-devel] [PATCH v7 00/10] i8254, i8259 and running Microport UNIX (ca 1987) |
Date: |
Tue, 11 Dec 2012 18:19:56 +0200 |
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.