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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 5436 bytes --]

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.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]