Re: [PATCH for-5.0 v2 0/9] q35: CPU hotplug with secure boot, part 1+2

[Igor Mammedov <imammedo@redhat.com>]

On Thu, 19 Dec 2019 14:30:51 +0100
Igor Mammedov <imammedo@redhat.com> wrote:

> On Mon,  9 Dec 2019 14:08:53 +0100
> Igor Mammedov <imammedo@redhat.com> 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.  
> 
> Michael,
> 
> could you pick it up please?

modulo 1/9 which has been merged via s390 tree,
the rest still applies fine current master

> 
> > 
> > CC: mst@redhat.com
> > CC: pbonzini@redhat.com
> > CC: lersek@redhat.com
> > CC: philmd@redhat.com
> > 
> > 
> > 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(-)
> >   
> 
>