From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7bcL-0001Oa-Qj for qemu-devel@nongnu.org; Tue, 31 May 2016 00:49:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b7bcG-0000Ca-IW for qemu-devel@nongnu.org; Tue, 31 May 2016 00:49:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7bcG-0000CP-9t for qemu-devel@nongnu.org; Tue, 31 May 2016 00:49:20 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7727881F07 for ; Tue, 31 May 2016 04:49:19 +0000 (UTC) Date: Tue, 31 May 2016 07:49:16 +0300 From: "Michael S. Tsirkin" Message-ID: <20160531044916.GA11176@redhat.com> References: <1463496205-251412-1-git-send-email-imammedo@redhat.com> <1463496205-251412-16-git-send-email-imammedo@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1463496205-251412-16-git-send-email-imammedo@redhat.com> Subject: Re: [Qemu-devel] [PATCH 15/33] docs: update ACPI CPU hotplug spec with new protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: qemu-devel@nongnu.org, rkrcmar@redhat.com, ehabkost@redhat.com, drjones@redhat.com, armbru@redhat.com, marcel@redhat.com On Tue, May 17, 2016 at 04:43:07PM +0200, Igor Mammedov wrote: > Signed-off-by: Igor Mammedov > --- > docs/specs/acpi_cpu_hotplug.txt | 88 +++++++++++++++++++++++++++++++++++------ > 1 file changed, 76 insertions(+), 12 deletions(-) > > diff --git a/docs/specs/acpi_cpu_hotplug.txt b/docs/specs/acpi_cpu_hotplug.txt > index 340b751..c5bce6a 100644 > --- a/docs/specs/acpi_cpu_hotplug.txt > +++ b/docs/specs/acpi_cpu_hotplug.txt > @@ -4,21 +4,85 @@ QEMU<->ACPI BIOS CPU hotplug interface > QEMU supports CPU hotplug via ACPI. This document > describes the interface between QEMU and the ACPI BIOS. > > -ACPI GPE block (IO ports 0xafe0-0xafe3, byte access): > ------------------------------------------ > - > -Generic ACPI GPE block. Bit 2 (GPE.2) used to notify CPU > -hot-add/remove event to ACPI BIOS, via SCI interrupt. > +ACPI BIOS GPE.2 handler is dedicated for notifying OS about CPU hot-add > +and hot-remove events. > > +============================================ > +Legacy ACPI CPU hotplug interface registers: > +-------------------------------------------- > CPU present bitmap for: > + One bit per CPU. Bit position reflects corresponding CPU APIC ID. Read-only. > ICH9-LPC (IO port 0x0cd8-0xcf7, 1-byte access) > PIIX-PM (IO port 0xaf00-0xaf1f, 1-byte access) > --------------------------------------------------------------- > -One bit per CPU. Bit position reflects corresponding CPU APIC ID. > -Read-only. > +QEMU sets corresponding CPU bit on hot-add event and issues SCI > +with GPE.2 event set. CPU present map read by ACPI BIOS GPE.2 handler > +to notify OS about CPU hot-add events. CPU hot-remove isn't supported. > + > +===================================== > +ACPI CPU hotplug interface registers: > +------------------------------------- > +Register block base address: > + ICH9-LPC IO port 0x0cd8 > + PIIX-PM IO port 0xaf00 OK but this means we either use legacy or new one, bot both, which is problematic for people using old seabios without acpi loading support and with -M pc. I don't say we must support them with >255 CPUs, but I do say we should make an effort for simple setups with <255 CPUs. > +Register block size: > + ACPI_CPU_HOTPLUG_REG_LEN = 12 > + > +read access: So this implies acpi must scan all cpus on each event, and this seems too aggressive. I think we need something hierarchical where you read one level and know which cpus to probe. > + offset: > + [0x0-0x3] reserved > + [0x4] CPU device status fields: (1 byte access) > + bits: > + 0: Device is enabled and may be used by guest > + 1: Device insert event, used to distinguish device for which > + no device check event to OSPM was issued. > + It's valid only when bit 0 is set. > + 2: Device remove event, used to distinguish device for which > + no device eject request to OSPM was issued. > + 3-7: reserved and should be ignored by OSPM > + [0x5-0x7] reserved > + [0x8] Command data: (DWORD access) > + in case of error or unsupported command reads is 0xFFFFFFFF > + current 'Command field' value: > + 0: returns PXM value corresponding to device > + > +write access: > + offset: > + [0x0-0x3] CPU selector: (DWORD access) > + selects active CPU device. All following accesses to other > + registers will read/store data from/to selected CPU. I've been thinking - is it time to add an EmbeddedControl interface? This way we have another namespace. Not insisting on it, just an idea. > + [0x4] CPU device control fields: (1 byte access) > + bits: > + 0: reserved, OSPM must clear it before writing to register. > + 1: if set to 1 clears device insert event, set by OSPM > + after it has emitted device check event for the > + selected CPU device > + 2: if set to 1 clears device remove event, set by OSPM > + after it has emitted device eject request for the > + selected CPU device > + 3: if set to 1 initiates device eject, set by OSPM when it > + triggers CPU device removal and calls _EJ0 method > + 4-7: reserved, OSPM must clear them before writing to register > + [0x5] Command field: (1 byte access) > + value: > + 0: following reads from 'Command data' register returns PXM > + value of device > + 1: following writes to 'Command data' register set OST event > + register in QEMU > + 2: following writes to 'Command data' register set OST status > + register in QEMU > + other values: reserved > + [0x6-0x7] reserved > + [0x8] Command data: (DWORD access) > + current 'Command field' value: > + 1: stores value into OST event register > + 2: stores value into OST status register, triggers > + ACPI_DEVICE_OST QMP event from QEMU to external applications > + with current values of OST event and status registers. > + other values: reserved > > -CPU hot-add/remove notification: > ------------------------------------------------------ > -QEMU sets/clears corresponding CPU bit on hot-add/remove event. > -CPU present map read by ACPI BIOS GPE.2 handler to notify OS of CPU > -hot-(un)plug events. > +Selecting CPU device beyond possible range has no effect on platform: > + - write accesses to CPU hot-plug registers not documented above are > + ignored > + - read accesses to CPU hot-plug registers not documented above return > + all bits set to 1. why not 0? > -- > 1.8.3.1