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

[Anthony Liguori]

Jan Kiszka <address@hidden> 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

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