qemu-devel
[Top][All Lists]
Advanced

[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: Igor Mammedov
Subject: Re: [PATCH for-5.0 v2 0/9] q35: CPU hotplug with secure boot, part 1+2
Date: Mon, 6 Jan 2020 11:10:20 +0100

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)

> 
> 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(-)
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]