From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.groups.io with SMTP id smtpd.web12.5243.1571832357597116769 for ; Wed, 23 Oct 2019 05:05:57 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: philmd@redhat.com) Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DCF75369AC for ; Wed, 23 Oct 2019 12:05:56 +0000 (UTC) Received: by mail-wr1-f71.google.com with SMTP id x9so4488249wrq.5 for ; Wed, 23 Oct 2019 05:05:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YPzhU9D6e77xynno4+K/Xpig4JIzvg7TgClH3jcU+BU=; b=aKRt8qoM/iJ1J81YfmjXJmDmhbjMJH5r2Vfq7CIdqKENeKriK+W3Qmq2USQFOMhCT+ 8OfMYfgELXj7FRFQTMYIp0dRYIQS0fEozjgqHnLAWRTYD2/KlFrItzmQ3X0kf4YB/vQE f9Y2DzE9N3QqSz/9ceuI8ELXx6OsYEO79il8mshS+ulzUswCpQ/Y6knl0Xh3If5GMD91 PysCpaNR5h5SHXViWWYIpvQmDw9V3zRFb8J52q3un096zDotwg2LdjVxemm6kOoJxswh iA2DzeYUlZHS2JzEnRzJpT1PYmpnXdhKfDqG8kVX0gNdhL6ouJPoSdVh1nh0iBOCBRp4 MR2w== X-Gm-Message-State: APjAAAXs7atdkGffrfVaMWcB93V7Uutpwn/OZWfjwWpz7drnhUJf7IO5 6SxNaPx+bLviMDANfQrHoyoWOzTYex83XWp+ScUP533lNo+uXicQhJ+KZSEp/bBtJADH4gMg53g KmpR+5Ri0e57z6A== X-Received: by 2002:adf:fb0b:: with SMTP id c11mr8383095wrr.50.1571832355547; Wed, 23 Oct 2019 05:05:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqxhzTbF27TdBamw6WqI5Mrhb0ISxmIQSn6nI99fBJ8GYPfkBuEncKQ6fb+g5q73gC9YlPRC2g== X-Received: by 2002:adf:fb0b:: with SMTP id c11mr8383072wrr.50.1571832355309; Wed, 23 Oct 2019 05:05:55 -0700 (PDT) Received: from [192.168.1.41] (129.red-83-57-174.dynamicip.rima-tde.net. [83.57.174.129]) by smtp.gmail.com with ESMTPSA id t13sm28180211wra.70.2019.10.23.05.05.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Oct 2019 05:05:54 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH v2 2/3] OvmfPkg/IndustryStandard: define macros for QEMU's CPU hotplug registers To: devel@edk2.groups.io, lersek@redhat.com Cc: Ard Biesheuvel , Igor Mammedov , Jordan Justen References: <20191022221554.14963-1-lersek@redhat.com> <20191022221554.14963-3-lersek@redhat.com> From: =?UTF-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= Message-ID: <4cbe775a-ca0f-2c49-302a-50965360e508@redhat.com> Date: Wed, 23 Oct 2019 14:05:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191022221554.14963-3-lersek@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Laszlo, On 10/23/19 12:15 AM, Laszlo Ersek wrote: > In v1.5.0, QEMU's "pc" (i440fx) board gained a "CPU present bitmap" > register block. In v2.0.0, this was extended to the "q35" board. > > In v2.7.0, a new (read/write) register interface was laid over the "CPU > present bitmap", with an option for the guest to switch the register block > to the new (a.k.a. modern) interface. This historical information is helpful to understand when these QEMU models started to diverge from the original chipset datasheet. > Both interfaces are documented in "docs/specs/acpi_cpu_hotplug.txt" in the > QEMU tree. > > Add macros for a minimal subset of the modern interface, just so we can > count the possible CPUs (as opposed to boot CPUs) in a later patch in this > series. > > Cc: Ard Biesheuvel > Cc: Igor Mammedov > Cc: Jordan Justen > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 > Signed-off-by: Laszlo Ersek > --- > > Notes: > v2: > - use QEMU's existent CPU hotplug register block, rather than a new > named file in fw_cfg [Igor] > > OvmfPkg/Include/IndustryStandard/I440FxPiix4.h | 5 +++ > OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 2 + > OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h | 43 ++++++++++++++++++++ > 3 files changed, 50 insertions(+) > > diff --git a/OvmfPkg/Include/IndustryStandard/I440FxPiix4.h b/OvmfPkg/Include/IndustryStandard/I440FxPiix4.h > index e7d7fde14c65..3973ff0a95b4 100644 > --- a/OvmfPkg/Include/IndustryStandard/I440FxPiix4.h > +++ b/OvmfPkg/Include/IndustryStandard/I440FxPiix4.h > @@ -44,6 +44,11 @@ > BIT10 | BIT9 | BIT8 | BIT7 | BIT6) > > #define PIIX4_PMREGMISC 0x80 > #define PIIX4_PMREGMISC_PMIOSE BIT0 > > +// > +// IO ports > +// > +#define PIIX4_CPU_HOTPLUG_BASE 0xAF00 OK > + > #endif > diff --git a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h > index 391cb4622226..2ac16f19c62e 100644 > --- a/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h > +++ b/OvmfPkg/Include/IndustryStandard/Q35MchIch9.h > @@ -104,10 +104,12 @@ > // IO ports > // > #define ICH9_APM_CNT 0xB2 > #define ICH9_APM_STS 0xB3 > > +#define ICH9_CPU_HOTPLUG_BASE 0x0CD8 OK > + > // > // IO ports relative to PMBASE > // > #define ICH9_PMBASE_OFS_SMI_EN 0x30 > #define ICH9_SMI_EN_APMC_EN BIT5 > diff --git a/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h b/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h > new file mode 100644 > index 000000000000..cf0745610f2c > --- /dev/null > +++ b/OvmfPkg/Include/IndustryStandard/QemuCpuHotplug.h > @@ -0,0 +1,43 @@ > +/** @file > + Macros for accessing QEMU's CPU hotplug register block. > + > + Copyright (C) 2019, Red Hat, Inc. > + > + SPDX-License-Identifier: BSD-2-Clause-Patent > + > + @par Specification Reference: > + > + - "docs/specs/acpi_cpu_hotplug.txt" in the QEMU source tree. > + > + The original (now "legacy") CPU hotplug interface appeared in QEMU v1.5.0. > + The new ("modern") hotplug interface appeared in QEMU v2.7.0. > + > + The macros in this header file map to the minimal subset of the modern > + interface that OVMF needs. > +**/ > + > +#ifndef QEMU_CPU_HOTPLUG_H_ > +#define QEMU_CPU_HOTPLUG_H_ > + > +#include > + > +// > +// Each register offset is: > +// - relative to the board-dependent IO base address of the register block, > +// - named QEMU_CPUHP_(R|W|RW)_*, according to the possible access modes of the > +// register, > +// - followed by distinguished bitmasks or values in the register. > +// > +#define QEMU_CPUHP_R_CMD_DATA2 0x0 I don't understand this one. Read register 0x0 is marked "reserved" in the spec, and CMD_DATA are registers [0x8 .. 0xb]. > + > +#define QEMU_CPUHP_R_CPU_STAT 0x4 > +#define QEMU_CPUHP_STAT_ENABLED BIT0 OK > + > +#define QEMU_CPUHP_RW_CMD_DATA 0x8 Here the spec says "DWORD access" but the implementation use "BYTE access" (see AcpiCpuHotplug_ops in hw/acpi/cpu_hotplug.c). I understand this as "there are 4 consecutive BYTE register). Not this patch problem although. > + > +#define QEMU_CPUHP_W_CPU_SEL 0x0 Another "DWORD access". OK. > + > +#define QEMU_CPUHP_W_CMD 0x5 > +#define QEMU_CPUHP_CMD_GET_PENDING 0x0 'PENDING' is more meaningful than "CPU device with inserting/removing events". OK > + > +#endif // QEMU_CPU_HOTPLUG_H_ >