public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	qemu devel list <qemu-devel@nongnu.org>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Chen, Yingwen" <yingwen.chen@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Joao Marcal Lemos Martins <joao.m.martins@oracle.com>,
	Phillip Goerl <phillip.goerl@oracle.com>
Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
Date: Fri, 23 Aug 2019 15:25:00 +0000	[thread overview]
Message-ID: <E92EE9817A31E24EB0585FDF735412F5B9DA25CC@ORSMSX113.amr.corp.intel.com> (raw)
In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503F76FDAF@shsmsx102.ccr.corp.intel.com>

Hi Jiewen,

If a hot add CPU needs to run any code before the
first SMI, I would recommend is only executes code
from a write protected FLASH range without a stack
and then wait for the first SMI.

For this OVMF use case, is any CPU init required
before the first SMI?

From Paolo's list of steps are steps (8a) and (8b) 
really required?  Can the SMI monarch use the Local
APIC to send a directed SMI to the hot added CPU?
The SMI monarch needs to know the APIC ID of the
hot added CPU.  Do we also need to handle the case
where multiple CPUs are added at once?  I think we
would need to serialize the use of 3000:8000 for the
SMM rebase operation on each hot added CPU.

It would be simpler if we can guarantee that only
one CPU can be added or removed at a time and the 
complete flow of adding a CPU to SMM and the OS
needs to be completed before another add/remove
event needs to be processed.

Mike

> -----Original Message-----
> From: Yao, Jiewen
> Sent: Thursday, August 22, 2019 10:00 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>;
> Paolo Bonzini <pbonzini@redhat.com>; Laszlo Ersek
> <lersek@redhat.com>; rfc@edk2.groups.io
> Cc: Alex Williamson <alex.williamson@redhat.com>;
> devel@edk2.groups.io; qemu devel list <qemu-
> devel@nongnu.org>; Igor Mammedov <imammedo@redhat.com>;
> Chen, Yingwen <yingwen.chen@intel.com>; Nakajima, Jun
> <jun.nakajima@intel.com>; Boris Ostrovsky
> <boris.ostrovsky@oracle.com>; Joao Marcal Lemos Martins
> <joao.m.martins@oracle.com>; Phillip Goerl
> <phillip.goerl@oracle.com>
> Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with QEMU+OVMF
> 
> Thank you Mike!
> 
> That is good reference on the real hardware behavior.
> (Glad it is public.)
> 
> For threat model, the unique part in virtual environment
> is temp RAM.
> The temp RAM in real platform is per CPU cache, while
> the temp RAM in virtual platform is global memory.
> That brings one more potential attack surface in virtual
> environment, if hot-added CPU need run code with stack
> or heap before SMI rebase.
> 
> Other threats, such as SMRAM or DMA, are same.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -----Original Message-----
> > From: Kinney, Michael D
> > Sent: Friday, August 23, 2019 9:03 AM
> > To: Paolo Bonzini <pbonzini@redhat.com>; Laszlo Ersek
> > <lersek@redhat.com>; rfc@edk2.groups.io; Yao, Jiewen
> > <jiewen.yao@intel.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> > Cc: Alex Williamson <alex.williamson@redhat.com>;
> > devel@edk2.groups.io; qemu devel list <qemu-
> devel@nongnu.org>; Igor
> > Mammedov <imammedo@redhat.com>; Chen, Yingwen
> > <yingwen.chen@intel.com>; Nakajima, Jun
> <jun.nakajima@intel.com>;
> > Boris Ostrovsky <boris.ostrovsky@oracle.com>; Joao
> Marcal Lemos
> > Martins <joao.m.martins@oracle.com>; Phillip Goerl
> > <phillip.goerl@oracle.com>
> > Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using
> SMM with
> > QEMU+OVMF
> >
> > Paolo,
> >
> > I find the following links related to the discussions
> here along with
> > one example feature called GENPROTRANGE.
> >
> > https://csrc.nist.gov/CSRC/media/Presentations/The-
> Whole-is-Greater/im
> > a ges-media/day1_trusted-computing_200-250.pdf
> > https://cansecwest.com/slides/2017/CSW2017_Cuauhtemoc-
> Rene_CPU_Ho
> > t-Add_flow.pdf
> > https://www.mouser.com/ds/2/612/5520-5500-chipset-ioh-
> datasheet-1131
> > 292.pdf
> >
> > Best regards,
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> > > Sent: Thursday, August 22, 2019 4:12 PM
> > > To: Kinney, Michael D <michael.d.kinney@intel.com>;
> Laszlo Ersek
> > > <lersek@redhat.com>; rfc@edk2.groups.io; Yao, Jiewen
> > > <jiewen.yao@intel.com>
> > > Cc: Alex Williamson <alex.williamson@redhat.com>;
> > > devel@edk2.groups.io; qemu devel list <qemu-
> devel@nongnu.org>; Igor
> > > Mammedov <imammedo@redhat.com>; Chen, Yingwen
> > > <yingwen.chen@intel.com>; Nakajima, Jun
> <jun.nakajima@intel.com>;
> > > Boris Ostrovsky <boris.ostrovsky@oracle.com>; Joao
> Marcal Lemos
> > > Martins <joao.m.martins@oracle.com>; Phillip Goerl
> > > <phillip.goerl@oracle.com>
> > > Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug
> using SMM with
> > > QEMU+OVMF
> > >
> > > On 23/08/19 00:32, Kinney, Michael D wrote:
> > > > Paolo,
> > > >
> > > > It is my understanding that real HW hot plug uses
> the
> > > SDM defined
> > > > methods.  Meaning the initial SMI is to 3000:8000
> and
> > > they rebase to
> > > > TSEG in the first SMI.  They must have chipset
> specific
> > > methods to
> > > > protect 3000:8000 from DMA.
> > >
> > > It would be great if you could check.
> > >
> > > > Can we add a chipset feature to prevent DMA to
> 64KB
> > > range from
> > > > 0x30000-0x3FFFF and the UEFI Memory Map and ACPI
> > > content can be
> > > > updated so the Guest OS knows to not use that
> range for
> > > DMA?
> > >
> > > If real hardware does it at the chipset level, we
> will probably use
> > > Igor's suggestion of aliasing A-seg to 3000:0000.
> Before starting
> > > the new CPU, the SMI handler can prepare the SMBASE
> relocation
> > > trampoline at
> > > A000:8000 and the hot-plugged CPU will find it at
> > > 3000:8000 when it receives the initial SMI.  Because
> this is backed
> > > by RAM at 0xA0000-0xAFFFF, DMA cannot access it and
> would still go
> > > through to RAM at 0x30000.
> > >
> > > Paolo

  reply	other threads:[~2019-08-23 15:25 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13 14:16 CPU hotplug using SMM with QEMU+OVMF Laszlo Ersek
2019-08-13 16:09 ` Laszlo Ersek
2019-08-13 16:18   ` Laszlo Ersek
2019-08-14 13:20   ` Yao, Jiewen
2019-08-14 14:04     ` Paolo Bonzini
2019-08-15  9:55       ` Yao, Jiewen
2019-08-15 16:04         ` Paolo Bonzini
2019-08-15 15:00       ` [edk2-devel] " Laszlo Ersek
2019-08-15 16:16         ` Igor Mammedov
2019-08-15 16:21         ` Paolo Bonzini
2019-08-16  2:46           ` Yao, Jiewen
2019-08-16  7:20             ` Paolo Bonzini
2019-08-16  7:49               ` Yao, Jiewen
2019-08-16 20:15                 ` Laszlo Ersek
2019-08-16 22:19                   ` Alex Williamson
2019-08-17  0:20                     ` Yao, Jiewen
2019-08-18 19:50                       ` Paolo Bonzini
2019-08-18 23:00                         ` Yao, Jiewen
2019-08-19 14:10                           ` Paolo Bonzini
2019-08-21 12:07                             ` Laszlo Ersek
2019-08-21 15:48                           ` [edk2-rfc] " Michael D Kinney
2019-08-21 17:05                             ` Paolo Bonzini
2019-08-21 17:25                               ` Michael D Kinney
2019-08-21 17:39                                 ` Paolo Bonzini
2019-08-21 20:17                                   ` Michael D Kinney
2019-08-22  6:18                                     ` Paolo Bonzini
2019-08-22 18:29                                       ` Laszlo Ersek
2019-08-22 18:51                                         ` Paolo Bonzini
2019-08-23 14:53                                           ` Laszlo Ersek
2019-08-22 20:13                                         ` Michael D Kinney
2019-08-22 17:59                               ` Laszlo Ersek
2019-08-22 18:43                                 ` Paolo Bonzini
2019-08-22 20:06                                   ` Michael D Kinney
2019-08-22 22:18                                     ` Paolo Bonzini
2019-08-22 22:32                                       ` Michael D Kinney
2019-08-22 23:11                                         ` Paolo Bonzini
2019-08-23  1:02                                           ` Michael D Kinney
2019-08-23  5:00                                             ` Yao, Jiewen
2019-08-23 15:25                                               ` Michael D Kinney [this message]
2019-08-24  1:48                                                 ` Yao, Jiewen
2019-08-27 18:31                                                   ` Igor Mammedov
2019-08-29 17:01                                                     ` Laszlo Ersek
2019-08-30 14:48                                                       ` Igor Mammedov
2019-08-30 18:46                                                         ` Laszlo Ersek
2019-09-02  8:45                                                           ` Igor Mammedov
2019-09-02 19:09                                                             ` Laszlo Ersek
2019-09-03 14:53                                                               ` [Qemu-devel] " Igor Mammedov
2019-09-03 17:20                                                                 ` Laszlo Ersek
2019-09-04  9:52                                                                   ` imammedo
2019-09-05 13:08                                                                     ` Laszlo Ersek
2019-09-05 15:45                                                                       ` Igor Mammedov
2019-09-05 15:49                                                                       ` [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address Igor Mammedov
2019-09-09 19:15                                                                         ` Laszlo Ersek
2019-09-09 19:20                                                                           ` Laszlo Ersek
2019-09-10 15:58                                                                           ` Igor Mammedov
2019-09-11 17:30                                                                             ` Laszlo Ersek
2019-09-17 13:11                                                                               ` [edk2-devel] " Igor Mammedov
2019-09-17 14:38                                                                                 ` [staging/branch]: CdePkg - C Development Environment Package Minnow Ware
2019-08-26 15:30                                                 ` [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF Laszlo Ersek
2019-08-27 16:23                                                   ` Igor Mammedov
2019-08-27 20:11                                                     ` Laszlo Ersek
2019-08-28 12:01                                                       ` Igor Mammedov
2019-08-29 16:25                                                         ` Laszlo Ersek
2019-08-30 13:49                                                           ` [Qemu-devel] " Igor Mammedov
2019-08-22 17:53                             ` Laszlo Ersek
2019-08-16 20:00           ` Laszlo Ersek
2019-08-15 16:07       ` Igor Mammedov
2019-08-15 16:24         ` Paolo Bonzini
2019-08-16  7:42           ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E92EE9817A31E24EB0585FDF735412F5B9DA25CC@ORSMSX113.amr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox