Re: [Qemu-devel] [PATCH v4 5/5] i8259: fix dynamically masking slave IRQs with IMR register

[Avi Kivity <avi@redhat.com>]

On 09/04/2012 12:29 PM, BALATON Zoltan wrote:
> On Tue, 4 Sep 2012, Avi Kivity wrote:
>> On 09/04/2012 12:15 PM, Paolo Bonzini wrote:
>>> Il 04/09/2012 10:16, Avi Kivity ha scritto:
>>>>>> But the point of subsections is to succeed migration in the common
>>>>>> case,
>>>>>> assuming there is more than one case that doesn't affect guest
>>>>>> operation.
>>>> According to the patch, if icw3 == 4 && !(eclr & 4), then behaviour
>>>> will
>>>> change.  With the standard configuration, if two pci interrupts hit at
>>>> once, then before the patch irr.2 will be clear, and afterwards set.
>>>>
>>>> So we do have a behavioural change.  Is the rest of the code masking
>>>> this change under the standard configuration?
>>>
>>> No, it is not masking the change.  The assumption is that nothing should
>>> care about irr.2 or isr.2, because nothing attaches an handler to the
>>> cascade interrupt.
>>
>> Won't the next call to pic_get_irq() notice the difference in s->irr?
>>
>>> You have to choose between assuming this, and breaking backwards
>>> migration.  I would rather break backwards migration, but others
>>> disagree...
>>
>> Normally I'd agree, but if the only known breakee is a 1987 guest then
>> I'd make an exception.
> 
> Another one affected by this is OpenStep 4.2 (probably NeXTstep and
> Rhapsody too) which are not exactly recent either but there are more
> than only one "breakee".

Those are all filed under "esoterics".

I don't mean to say we shouldn't care about them, but there are likely
to be a lot more users doing backwards migration than users running
those guests, let alone migrating them (forwards or backwards).  The
pragmatic choice is clear.

-- 
error compiling committee.c: too many arguments to function