[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-5.0 v2 0/9] q35: CPU hotplug with secure boot, part 1+2
From: |
Michael S. Tsirkin |
Subject: |
Re: [PATCH for-5.0 v2 0/9] q35: CPU hotplug with secure boot, part 1+2 |
Date: |
Mon, 6 Jan 2020 05:22:57 -0500 |
On Mon, Jan 06, 2020 at 11:10:20AM +0100, Igor Mammedov wrote:
> On Mon, 9 Dec 2019 14:08:53 +0100
> Igor Mammedov <address@hidden> wrote:
>
> > ChangeLog:
> > * since v1:
> > - include "hw: add compat machines for 5.0" to provide
> > compat context for 4.2 machine types
> > - add comment that SMRAM at SMBASE is QEMU hack
> > and why it was used
> > - split command data 2 into a separate patch
> > "acpi: cpuhp: introduce 'Command data 2' field"
> > - rewrite enabling/detecting modern CPU hotplug interface
> > to use existing CPHP_GET_NEXT_CPU_WITH_EVENT_CMD and
> > squash it into "acpi: cpuhp: spec: add typical usecases" patch
> > - "acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command"
> > modulo 'Command data 2' being moved out into separate patch,
> > rewrite commit message to explain better why new command is needed.
> >
> >
> > Series consists of 2 parts: 1st is lockable SMRAM at SMBASE
> > and the 2nd better documents interface and adds means to
> > enumerate APIC IDs for possible CPUs.
> >
> > 1st part [1-2/9]:
> > In order to support CPU hotplug in secure boot mode,
> > UEFI firmware needs to relocate SMI handler of hotplugged CPU,
> > in a way that won't allow ring 0 user to break in priveleged
> > SMM mode that firmware maintains during runtime.
> > Used approach allows to hide RAM at default SMBASE to make it
> > accessible only to SMM mode, which lets us to make sure that
> > SMI handler installed by firmware can not be hijacked by
> > unpriveleged user (similar to TSEG behavior).
> >
> > 2nd part:
> > mostly fixes and extra documentation on how to detect and use
> > modern CPU hotplug interface (MMIO block).
> > So firmware could reuse it for enumerating possible CPUs and
> > detecting hotplugged CPU(s). It also adds support for
> > CPHP_GET_CPU_ID_CMD command [7/8], which should allow firmware
> > to fetch APIC IDs for possible CPUs which is necessary for
> > initializing internal structures for possible CPUs on boot.
>
> ping,
>
> Michael,
> could you merge series via your tree?
>
> (PS: series still applies fine to today's master)
I'm still waiting for Peter to apply my previous pull.
Will queue after that, thanks!
> >
> > CC: address@hidden
> > CC: address@hidden
> > CC: address@hidden
> > CC: address@hidden
> >
> >
> > Cornelia Huck (1):
> > hw: add compat machines for 5.0
> >
> > Igor Mammedov (8):
> > q35: implement 128K SMRAM at default SMBASE address
> > tests: q35: MCH: add default SMBASE SMRAM lock test
> > acpi: cpuhp: spec: clarify 'CPU selector' register usage and
> > endianness
> > acpi: cpuhp: spec: fix 'Command data' description
> > acpi: cpuhp: spec: clarify store into 'Command data' when 'Command
> > field' == 0
> > acpi: cpuhp: introduce 'Command data 2' field
> > acpi: cpuhp: spec: add typical usecases
> > acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command
> >
> > include/hw/boards.h | 3 ++
> > include/hw/i386/pc.h | 3 ++
> > include/hw/pci-host/q35.h | 10 ++++
> > docs/specs/acpi_cpu_hotplug.txt | 89 +++++++++++++++++++++++++++-------
> > hw/acpi/cpu.c | 18 +++++++
> > hw/acpi/trace-events | 1 +
> > hw/arm/virt.c | 7 ++-
> > hw/core/machine.c | 3 ++
> > hw/i386/pc.c | 5 ++
> > hw/i386/pc_piix.c | 14 +++++-
> > hw/i386/pc_q35.c | 13 ++++-
> > hw/pci-host/q35.c | 84 +++++++++++++++++++++++++++++---
> > hw/ppc/spapr.c | 15 +++++-
> > hw/s390x/s390-virtio-ccw.c | 14 +++++-
> > tests/q35-test.c | 105
> > ++++++++++++++++++++++++++++++++++++++++
> > 15 files changed, 354 insertions(+), 30 deletions(-)
> >