From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrMak-0007rN-98 for qemu-devel@nongnu.org; Thu, 20 Nov 2014 02:55:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrMae-0001b5-4X for qemu-devel@nongnu.org; Thu, 20 Nov 2014 02:55:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrMad-0001ax-PV for qemu-devel@nongnu.org; Thu, 20 Nov 2014 02:55:44 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAK7thkR006060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 20 Nov 2014 02:55:43 -0500 Date: Thu, 20 Nov 2014 09:55:40 +0200 From: "Michael S. Tsirkin" Message-ID: <20141120075540.GA2808@redhat.com> References: <1412607364-14141-1-git-send-email-pbonzini@redhat.com> <5462439F.6080401@redhat.com> <546D8491.2010000@redhat.com> <20141120065545.GC30994@redhat.com> <546D9409.9090608@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546D9409.9090608@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On Thu, Nov 20, 2014 at 08:11:05AM +0100, Paolo Bonzini wrote: > > > On 20/11/2014 07:55, Michael S. Tsirkin wrote: > > I thought we agreed we'll consider alternate approaches after 2.2? > > I would prefer not to have yet another mode to support > > if we can help it. > > I agree, but: > > 1) looks like there is stronger opposition to your patch than I thought, > so a 2.2 solution as in this patch becomes more palatable Why the urgency? It's not fixing any regressions, is it? I would rather not add yet another mode for 2.2, we'll likely have a new mode in 2.3 but I'd like that to be the last one. > 2) reviewing patches is always nice, and helps evaluating the advantages > of either approach > > Paolo I'll do my best, sorry about the delay - I'm trying to prioritize 2.2 work at the moment. -- MST