From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8pEn-0006Qf-C5 for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:16:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8pEd-0002I5-Ij for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:16:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8pEd-0002Hq-A4 for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:15:51 -0400 Message-ID: <5045C6BF.3040207@redhat.com> Date: Tue, 04 Sep 2012 11:15:43 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <5045B8E3.9070305@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: "qemu-devel@nongnu.org" , Jan Kiszka , Matthew Ogilvie , =?UTF-8?B?QW5kcmVhcyBGw6Ry?= =?UTF-8?B?YmVy?= , "quintela@redhat.com" 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. You have to choose between assuming this, and breaking backwards migration. I would rather break backwards migration, but others disagree... Paolo