From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WX3Sz-0000fx-DC for qemu-devel@nongnu.org; Mon, 07 Apr 2014 02:55:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WX3Ss-0005RO-W1 for qemu-devel@nongnu.org; Mon, 07 Apr 2014 02:55:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WX3Ss-0005RC-M2 for qemu-devel@nongnu.org; Mon, 07 Apr 2014 02:55:30 -0400 Date: Mon, 7 Apr 2014 08:55:11 +0200 From: Igor Mammedov Message-ID: <20140407085511.0bab1988@nial.usersys.redhat.com> In-Reply-To: <20140404171404.GD31432@otherpad.lan.raisama.net> References: <1396618620-27823-1-git-send-email-imammedo@redhat.com> <1396618620-27823-15-git-send-email-imammedo@redhat.com> <20140404171404.GD31432@otherpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 14/35] pc: exit QEMU if slots > 256 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: peter.maydell@linaro.org, mst@redhat.com, aik@ozlabs.ru, hutao@cn.fujitsu.com, mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com, kraxel@redhat.com, akong@redhat.com, quintela@redhat.com, armbru@redhat.com, aliguori@amazon.com, jan.kiszka@siemens.com, lersek@redhat.com, marcel.a@redhat.com, stefanha@redhat.com, chegu_vinod@hp.com, rth@twiddle.net, kwolf@redhat.com, s.priebe@profihost.ag, mreitz@redhat.com, vasilis.liaskovitis@profitbricks.com, pbonzini@redhat.com, afaerber@suse.de On Fri, 4 Apr 2014 14:14:04 -0300 Eduardo Habkost wrote: > On Fri, Apr 04, 2014 at 03:36:39PM +0200, Igor Mammedov wrote: > > ... which is current ACPI implementation limit. > > > > Signed-off-by: Igor Mammedov > > With this we will have yet another hardcoded limit/assumption scattererd > in different places around the code, which we won't know how/if it can > be changed in the future. > > I would prefer to have a #define and an explanation on the code for the > specific limit, so people know if/when/how it is safe to change it a few > years from now. > > Something like: > > hw/acpi/acpi.h: > /* current device naming scheme dosen't support > * more that 256 memory devices > */ > #define ACPI_MAX_RAM_SLOTS 256 > > hw/acpi/acpi-build.c:build_ssdt(): > assert(nr_mem <= ACPI_MAX_RAM_SLOTS) > > hw/i386/pc.c: > if (machine->init_args.ram_slots > ACPI_MAX_RAM_SLOTS) { > error_report("unsupported amount of memory slots: %"PRIu64, > machine->init_args.ram_slots); > exit(EXIT_FAILURE); > } sure, I'll fix it for the next series respin. > > > --- > > hw/i386/pc.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > > index 69e4225..6fe1803 100644 > > --- a/hw/i386/pc.c > > +++ b/hw/i386/pc.c > > @@ -1204,6 +1204,12 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory, > > ram_addr_t hotplug_mem_size = > > machine->init_args.maxram_size - ram_size; > > > > + if (machine->init_args.ram_slots > 256) { > > + error_report("unsupported amount of memory slots: %"PRIu64, > > + machine->init_args.ram_slots); > > + exit(EXIT_FAILURE); > > + } > > + > > pcms->hotplug_memory_base = > > ROUND_UP(0x100000000ULL + above_4g_mem_size, 1ULL << 30); > > > > -- > > 1.9.0 > > >