[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF |
Date: |
Thu, 5 Sep 2019 15:08:31 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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).
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.
Thanks
Laszlo
- Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Igor Mammedov, 2019/09/02
- Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Laszlo Ersek, 2019/09/02
- Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Igor Mammedov, 2019/09/03
- Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Laszlo Ersek, 2019/09/03
- Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Igor Mammedov, 2019/09/04
- Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF,
Laszlo Ersek <=
- Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Igor Mammedov, 2019/09/05
- [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address, Igor Mammedov, 2019/09/05
- Re: [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address, Laszlo Ersek, 2019/09/09
- Re: [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address, Laszlo Ersek, 2019/09/09
- Re: [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address, Igor Mammedov, 2019/09/10
- Re: [Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address, Laszlo Ersek, 2019/09/11
- Re: [Qemu-devel] [edk2-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address, Igor Mammedov, 2019/09/17