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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-09-04 11:37, Avi Kivity wrote:
> 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.

BTW, did anyone actually test backward migration recently? I thought to
remember I effectively broke it in 1.1 with some changes to the i8259
(or was it the PIT?) vmstate, and no one really cared about this or my
first proposals to fix it.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux