From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPy73-000678-90 for qemu-devel@nongnu.org; Tue, 18 Mar 2014 13:47:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPy6t-0004Z0-Sf for qemu-devel@nongnu.org; Tue, 18 Mar 2014 13:47:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPy6t-0004Yr-Kq for qemu-devel@nongnu.org; Tue, 18 Mar 2014 13:47:31 -0400 Message-ID: <532886AC.3060403@redhat.com> Date: Tue, 18 Mar 2014 18:47:24 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1395072317-15679-1-git-send-email-lersek@redhat.com> <1395072317-15679-3-git-send-email-lersek@redhat.com> <20140318140325.GA16701@redhat.com> <20140318145435.GB13268@otherpad.lan.raisama.net> In-Reply-To: <20140318145435.GB13268@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [for-2.1 PATCH v2 2/2] i386/acpi-build: support hotplug of VCPU with APIC ID 0xFF List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , "Michael S. Tsirkin" Cc: imammedo@redhat.com, qemu-devel@nongnu.org, afaerber@suse.de On 03/18/14 15:54, Eduardo Habkost wrote: > On Tue, Mar 18, 2014 at 04:03:25PM +0200, Michael S. Tsirkin wrote: >> On Mon, Mar 17, 2014 at 05:05:17PM +0100, Laszlo Ersek wrote: >>> Building on the previous patch, raise the maximal count of processor >>> objects / NTFY branches / CPON elements from 255 to 256. This allows the >>> VCPU with APIC ID 0xFF to be hotplugged. >>> >>> Signed-off-by: Laszlo Ersek >> >> >> I note that we still have: >> if (endvalue >= MAX_CPUMASK_BITS) { >> endvalue = MAX_CPUMASK_BITS - 1; >> fprintf(stderr, >> "qemu: NUMA: A max of %d VCPUs are supported\n", >> MAX_CPUMASK_BITS); >> } >> and MAX_CPUMASK_BITS is 255. >> >> Seems inconsistent? >> > > MAX_CPUMASK_BITS (now renamed to MAX_CPUS) limits CPU indexes and total > CPU count. This patch is about APIC IDs (which may be larger than > max_cpus if threads-per-core or cores-per-socket is not a power of 2). Yea I welcome Eduardo's patchset not only because it fixes the out-of-range accesses caused by "uncontrolled" APIC IDs, but also because it disentangles these limits from one another. Thanks Laszlo