From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50585) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8pZv-0003RK-RX for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:37:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8pZp-0001DA-2I for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:37:51 -0400 Received: from mono.eik.bme.hu ([152.66.115.2]:46967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8pZo-0001Cm-RH for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:37:44 -0400 Date: Tue, 4 Sep 2012 11:29:31 +0200 (CEST) From: BALATON Zoltan In-Reply-To: <5045C7CB.5030307@redhat.com> Message-ID: References: <1346640974-30974-1-git-send-email-mmogilvi_qemu@miniinfo.net> <1346640974-30974-6-git-send-email-mmogilvi_qemu@miniinfo.net> <50446D11.5050904@suse.de> <5044C10D.7050600@redhat.com> <87fw6z5d0e.fsf@elfo.mitica> <5044D243.3050506@redhat.com> <5044D2A7.7000609@siemens.com> <5044D36E.3060505@redhat.com> <5044D494.3070304@siemens.com> <5044D78D.1060803@redhat.com> <5044D96C.3000406@redhat.com> <5044DB34.7030305@redhat.com> <5044DBEC.4020601@redhat.com> <5045B8E3.9070305@redhat.com> <5045C6BF.3040207@redhat.com> <5045C7CB.5030307@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Qemu-devel] [PATCH v4 5/5] i8259: fix dynamically masking slave IRQs with IMR register List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "quintela@redhat.com" , Jan Kiszka , "qemu-devel@nongnu.org" , =?UTF-8?B?QW5kcmVhcyBGw6Ry?= =?UTF-8?B?YmVy?= , Paolo Bonzini , Matthew Ogilvie 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". Regards, BALATON Zoltan