Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

From: Igor Mammedov <imammedo@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "Chen, Yingwen" <yingwen.chen@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	Phillip Goerl <phillip.goerl@oracle.com>,
	qemu devel list <qemu-devel@nongnu.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>,
	Joao Marcal Lemos Martins <joao.m.martins@oracle.com>
Subject: Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
Date: Thu, 5 Sep 2019 17:45:03 +0200	[thread overview]
Message-ID: <20190905174503.2acaa46a@redhat.com> (raw)
In-Reply-To: <add488d0-df13-830f-28c5-c7232ccb741f@redhat.com>

On Thu, 5 Sep 2019 15:08:31 +0200
Laszlo Ersek <lersek@redhat.com> wrote:

> On 09/04/19 11:52, Igor Mammedov wrote:
> 
> >  it could be stolen RAM + black hole like TSEG, assuming fw can live without RAM(0x30000+128K) range
> >   (in this case fwcfg interface would only work for locking down the range)
> > 
> >  or
> > 
> >  we can actually have a dedicated SMRAM (like in my earlier RFC),
> >  in this case FW can use RAM(0x30000+128K) when SMRAM isn't mapped into RAM address space
> >  (in this case fwcfg would be used to temporarily map SMRAM into normal RAM and unmap/lock
> >   after SMI relocation handler was initialized).
> > 
> > If possible I'd prefer a simpler TSEG like variant.  
> 
> I think TSEG-like behavior is between these two. That is, I believe we
> should have explicit open/close/lock operations. And, when the range is
> closed (meaning, closed+unlocked, or closed+locked), then the black hole
> should take effect for code that's not running in SMM.
> 
> Put differently, its like the second choice, except the range never
> appears as normal RAM. "When SMRAM isn't mapped into RAM address space",
> then the address range shows "nothing" (black hole).
I guess we at point where patch is better then words, I'll send one as reply here shortly.
I've just implemented subset of above (opened, closed+locked).


> Regarding "fw can live without RAM(0x30000+128K) range" -- do you mean
> whether the firmware could use another RAM area for fw_cfg DMA?
> 
> If that's the question, then I wouldn't worry about it. I'd remove the
> 0x30000+128K range from the memory map, so the fw_cfg stuff (or anything
> else) would never allocate memory from the range. It's much more
> concerning to me however how the SMM infrastructure would deal with a
> hole in the memory map right there.
I didn't mean fwcfg in this context, what I meant if firmware were able
to avoid using RAM(0x30000+128K) range (since it becomes unusable after locking).
Looks like you just answered it here