Could we have an initial SMBASE that is within TSEG. If we bring in hot plug CPUs one at a time, then initial SMBASE in TSEG can reprogram the SMBASE to the correct value for that CPU. Can we add a

All of the CPUs are now in SMM, and INIT/SIPI/SIPI will be discarded before 07a, so this is okay. However I do see a problem, because a PCI device's DMA could overwrite 0x38000 between (06) and (10)

No, there could be real mode code using it. What we _could_ do is initialize SMBASE to 0xa0000, but I think it's better to not deviate too much from processor behavior (even if it's admittedly a

Paolo Bonzini <pbonzini@...> wrote: Looking at Q35 code and Seabios SMM relocation as example, if I see it right QEMU has: - SMRAM is aliased from DRAM at 0xa0000 - and TSEG steals

Indeed the SMRR would not cover the A-seg on real hardware. However, if the chipset allowed aliasing A-seg SMRAM to 0x30000, it would only be used for SMBASE relocation of hotplugged CPU. The

I most likely don't understand how this is supposed to work but aren't we here successfully reading SMRAM from non-SMM context, something we are not supposed to be able to do? -boris

it will allow us to hide sensetive SMM_BASE area from non SMM running env, that will allow us to ensure that hotplugged CPU will run trusted SMM BASE relocation code and we won't need to force all

Paolo Bonzini <pbonzini@...> wrote: My impression was that QEMU/KVM's SMM address space is accessible only from CPU in SMM mode, so SMM CPU should access in-depended SMRAM at 0x30000 in SMM

Sure. (01a) QEMU: create new CPU. The CPU already exists, but it does not start running code until unparked by the CPU hotplug controller. (01b) QEMU: trigger SCI (02-03) no equivalent (04)

Laszlo Ersek <lersek@...> wrote: it shouldn't matter where from management SMI comes if OS won't be able to actually trigger SMI with un-trusted content at SMBASE on hotplugged (parked)

The BSP starts running from 0xFFFFFFF0. APs do not start running at all and just sit waiting for an INIT-SIPI-SIPI sequence. Please see my proposal in the reply to Laszlo. Paolo

Correct. The 0x30000...0x3ffff area is the only problematic one; Igor's idea (or a variant, for example optionally remapping 0xa0000..0xaffff SMRAM to 0x30000) is becoming more and more

Laszlo Ersek <lersek@...> wrote: It depends. For starters, the vfio mapping API does not allow unmapping arbitrary sub-ranges of previous mappings. So the hole you want to punch would need

for purpose of demo SMRAM (at 0x30000) is aliased at a0000 in system address space for easy initialization of SMI entry point. Here is resulting debug output showing that RAM at 0x30000 is not

It's just a quick hack together with Seabios to show that normal RAM at 0x30000 is not affected by SMM relocation and dedicated SMRAM could be used for relocation without need to care about untrusted

Perhaps there is a way to avoid the 3000:8000 startup vector. If a CPU is added after a cold reset, it is already in a different state because one of the active CPUs needs to release it by

Alex, thank you for the help! Please let us know if we should remove you from the CC list, in order not to clutter your inbox. (I've kept your address for now, for saying thanks. Feel free to stop

in real world, we deprecate AB-seg usage because they are vulnerable to smm cache poison attack. I assume cache poison is out of scope in the virtual world, or there is a way to prevent ABseg cache

+Alex (direct question at the bottom) The magic is 07a itself, IIUC. The CPU hotplug controller would be accessible only in SMM. And until 07a happens, the new CPU ignores INIT/SIPI/SIPI even if