From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8pJ4-0007jb-9Y for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:20:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8pIu-0003gB-PW for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:20:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8pIu-0003fk-Hq for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:20:16 -0400 Message-ID: <5045C7CB.5030307@redhat.com> Date: Tue, 04 Sep 2012 12:20:11 +0300 From: Avi Kivity 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> <5045C6BF.3040207@redhat.com> In-Reply-To: <5045C6BF.3040207@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: Paolo Bonzini Cc: "qemu-devel@nongnu.org" , Jan Kiszka , Matthew Ogilvie , =?UTF-8?B?QW5kcmVhcyBGw6Ry?= =?UTF-8?B?YmVy?= , "quintela@redhat.com" 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. -- error compiling committee.c: too many arguments to function