From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8qcO-00028j-5x for qemu-devel@nongnu.org; Tue, 04 Sep 2012 06:44:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8qcK-0006BB-1P for qemu-devel@nongnu.org; Tue, 04 Sep 2012 06:44:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8qcJ-0006B5-Oo for qemu-devel@nongnu.org; Tue, 04 Sep 2012 06:44:23 -0400 Message-ID: <5045DB7D.9030004@redhat.com> Date: Tue, 04 Sep 2012 13:44:13 +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> <5045C7CB.5030307@redhat.com> <5045CBDF.6010203@redhat.com> <5045CF10.9000603@siemens.com> <5045D2A8.4020208@redhat.com> In-Reply-To: <5045D2A8.4020208@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: "quintela@redhat.com" , Jan Kiszka , "qemu-devel@nongnu.org" , =?ISO-8859-1?Q?Andreas_F=E4rber?= , Matthew Ogilvie On 09/04/2012 01:06 PM, Paolo Bonzini wrote: > Il 04/09/2012 11:51, Jan Kiszka ha scritto: >>> > >>> > 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. >> BTW, did anyone actually test backward migration recently? I thought to >> remember I effectively broke it in 1.1 with some changes to the i8259 >> (or was it the PIT?) vmstate, and no one really cared about this or my >> first proposals to fix it. > > Correct: commit ce967e2 (i8254: Rework & fix interaction with HPET in > legacy mode, 2012-02-01) bumped the PIT version from 2 to 3. Gah, this is 1.1, so there's no way to fix it. > RTC > changes will break it more in 1.3. > > Honestly, backwards migration only works on "enterprise" qemu-kvm > because it is tested only there. And so far the only sample across > major releases is that RHEL6->RHEL5 migration didn't work. I expect that we will want 7->6, though we may have to settle for minor releases only. > Here the choice is between changing guest behavior by defaulting to 4/2, > and always transmitting the subsection by defaulting to 0/0. The latter > makes the subsection useless, so at that point we might as well bump the > version number and board said flight to the Pacific. So we do the 4/2 thing. I expect if we go they'll tell us they don't do backwards flights. -- error compiling committee.c: too many arguments to function