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