From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8Zxq-00033z-Bp for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:58:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8ZxE-00041G-8h for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:57:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8ZxE-00041C-0f for qemu-devel@nongnu.org; Mon, 03 Sep 2012 12:56:52 -0400 Message-ID: <5044E14D.4070203@redhat.com> Date: Mon, 03 Sep 2012 18:56:45 +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> <5044DD67.6070003@siemens.com> In-Reply-To: <5044DD67.6070003@siemens.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: Jan Kiszka Cc: "qemu-devel@nongnu.org" , "quintela@redhat.com" , Avi Kivity , =?UTF-8?B?QW5kcmVhcyBGw6Q=?= =?UTF-8?B?cmJlcg==?= , Matthew Ogilvie Il 03/09/2012 18:40, Jan Kiszka ha scritto: >>> >> And the migration fails. Needlessly, since icw3 == 0 doesn't affect >>> >> guest operation. >> > >> > 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. > The point is that the common case is icw3 = 4 (for the master), not 0. > And if we don't save that case, we must save the rest. If we don't save > this as well, we lose state information. This can't work. I was agreeing with you, not Avi. :) Paolo