From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvLsJ-0006oM-IX for qemu-devel@nongnu.org; Sat, 18 Apr 2009 21:31:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvLsF-0006iX-V3 for qemu-devel@nongnu.org; Sat, 18 Apr 2009 21:31:15 -0400 Received: from [199.232.76.173] (port=37781 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvLsF-0006iN-QN for qemu-devel@nongnu.org; Sat, 18 Apr 2009 21:31:11 -0400 Received: from an-out-0708.google.com ([209.85.132.249]:32412) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LvLsE-0004Fy-VW for qemu-devel@nongnu.org; Sat, 18 Apr 2009 21:31:11 -0400 Received: by an-out-0708.google.com with SMTP id d11so344649and.37 for ; Sat, 18 Apr 2009 18:31:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1240001860-2280-1-git-send-email-glommer@redhat.com> <1240001860-2280-2-git-send-email-glommer@redhat.com> Date: Sun, 19 Apr 2009 11:01:09 +0930 Message-ID: From: Brendan Trotter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [Bochs-developers] [PATCH 1/2] create acpi cpu definitions Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bochs-developers@lists.sourceforge.net Cc: Glauber Costa , aliguori@us.ibm.com, qemu-devel@nongnu.org Hi, On Sun, Apr 19, 2009 at 7:20 AM, Sebastian Herbszt wrote: > Glauber Costa wrote: >> This comes directly from kvm-userspace. It creates >> the necessary infrastructure for cpu hotplug, by >> creating _MAT and _STA entries in cpu devices, >> and by allowing notifications to the guest to happen > > Is there a cpu hotplug specification? I would like to read up > on the needed changes. There isn't any CPU hotplug specification for 80x86. The "Processor Local APIC" structure in ACPI's tables has an "enabled/disabled" flag (just like some other structures in ACPI tables). Hotplug CPUs that aren't present may not be listed at all (no "disabled" entry), and "Processor Local APIC" entries may be disabled for any number of other reasons (including a BIOS that uses fixed size tables, that supports more CPUs than the motherboard). The only thing an OS can assume about disabled "Processor Local APIC" entries is that the OS must not attempt to use the CPU. For a comparison, the ACPI specification does include support for hotplug RAM. In this case (for ACPI 3.0) the "int 0x15, eax = 0xE820" BIOS function returns entries with an enabled/disabled flag where "disabled" entries must be ignored; and there's a completely separate structure (the "Memory Affinity Structure") which contains information about areas that are used for hot-plug RAM, which has it's one enabled/disabled flag *and* a separate hotpluggable/not hotpluggable flag. From this, it seems logical that if ACPI ever does support hot-plug CPUs, then they'll use a separate structure or a separate flag to indicate if a CPU is hot pluggable or not, and the existing "enabled/disabled" flag will retain it's current (use/don't use) meaning. For some reason (unknown to me) some Linux developers made wild assumptions about disabled "Processor Local APIC" entries, and now they're inventing fictitious hardware to support their unfounded assumptions. Please, correct me if I'm wrong... Cheers, Brendan