From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBsL3-00019r-U0 for qemu-devel@nongnu.org; Mon, 28 Jul 2014 17:20:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBsKw-0003vT-4F for qemu-devel@nongnu.org; Mon, 28 Jul 2014 17:20:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBsKv-0003uc-T8 for qemu-devel@nongnu.org; Mon, 28 Jul 2014 17:20:02 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6SLK0Du017583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 28 Jul 2014 17:20:01 -0400 Date: Mon, 28 Jul 2014 23:20:18 +0200 From: "Michael S. Tsirkin" Message-ID: <20140728212018.GA32206@redhat.com> References: <1406561658-6761-1-git-send-email-pbonzini@redhat.com> <1406561658-6761-4-git-send-email-pbonzini@redhat.com> <20140728155907.GA30104@redhat.com> <53D67595.2000702@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D67595.2000702@redhat.com> Subject: Re: [Qemu-devel] [PATCH 3/5] pc: future-proof migration-compatibility of ACPI tables List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: imammedo@redhat.com, lersek@redhat.com, qemu-devel@nongnu.org On Mon, Jul 28, 2014 at 06:08:53PM +0200, Paolo Bonzini wrote: > Il 28/07/2014 17:59, Michael S. Tsirkin ha scritto: > > On Mon, Jul 28, 2014 at 05:34:16PM +0200, Paolo Bonzini wrote: > >> This patch avoids that similar changes break QEMU again in the future. > >> QEMU will now hard-code 64k as the maximum ACPI table size, which > >> (despite being an order of magnitude smaller than 640k) should be enough > >> for everyone. > > > > Famous last words :) So what worries me here, is that we > > are potentially breaking legal configurations for the > > benefit of the minority that cares about cross-version > > migration. > > > > So I'm inclined to apply everything except this patch, and > > instead, use the patches that I sent to make the > > ram block very large, something like 1 Megabyte. > > Even just 128k are enough for 160 VCPUs, 255 memory slots and 35-40 PCI > bridges. And for 2.2 I'd rather move to the other model where all > user-defined elements (MADT, SSDT) are in a separate file and we > guarantee that *all* changes are versioned by machine type. > > What do you think about just changing 64k->128k? Your patch is a huge > amount of code for -rc4. > > Paolo True ... OK I applied this, and made minor tweaks on top. Any reviewers? -- MST