Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
On 08/22/19 20:51, Paolo Bonzini wrote:
On 22/08/19 20:29, Laszlo Ersek wrote:(1) Sorry, my _DMA quote was a detour from QEMU -- I wondered how aOn 08/22/19 08:18, Paolo Bonzini wrote:It's much simpler: these ranges are not in e820, for exampleOn 21/08/19 22:17, Kinney, Michael D wrote:This thread (esp. Jiewen's and Mike's messages) are the first time thatDMA protection of memory ranges is a chipset feature. For the currentYes.
physical machine with actual RAM at 0x30000, and also chipset level
protection against DMA to/from that RAM range, would expose the fact to
the OS (so that the OS not innocently try to set up DMA there).
(2) In case of QEMU+OVMF, "e820" is not defined at the firmware level.
- QEMU exports an "e820 map" (and OVMF does utilize that),
- and Linux parses the UEFI memmap into an "e820 map" (so that dependent
logic only need to deal with e820),
in edk2 the concepts are "GCD memory space map" and "UEFI memmap".
So what OVMF does is, it reserves the TSEG area in the UEFI memmap:
(This was later de-constified for the extended TSEG size, in commit
23bfb5c0aab6, "OvmfPkg/PlatformPei: prepare for PcdQ35TsegMbytes
becoming dynamic", 2017-07-05).
This is just to say that with OVMF, TSEG is not absent from the UEFI
memmap, it is reserved instead. (Apologies if I misunderstood and you
didn't actually claim otherwise.)
The ranges are not special-cased in any way by QEMU. Simply, AB-segs(or when TSEG is not locked, and open; but:) yes, this matches my
Therefore, DMA to those ranges ends up respectively to low VGA RAMWhich seems to imply that, if we alias 0x30000 to the AB-segs, and rely
on the AB-segs for CPU hotplug, OVMF should close and lock down the
AB-segs at first boot. Correct? (Because OVMF doesn't do anything about
AB at the moment.)