Note that it'd also be fine to match some kind of official Intel specification even if no processor (currently?) supports it. Yes. Paolo

Yes, all of these would work. Again, I'm interested in having something that has a hope of being implemented in real hardware. Another, far easier to implement possibility could be a lockable

The problem is not the SMRR but the SMBASE. If the SMBASE area is outside TSEG, it is vulnerable to DMA attacks independent of the SMRR. SMBASE is also different for all CPUs, so it cannot be

It's much simpler: these ranges are not in e820, for example kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000008bfff] usable kernel: BIOS-e820: [mem 0x000000000008c000-0x00000000000fffff]

No, that would be unmaintainable. The best solution to me seems to be to make SMBASE programmable from non-SMM code if some special conditions hold. Michael, would it be possible to get in contact

Laszlo, I believe all the code for the AP startup vector is already in edk2. It is a combination of the reset vector code in UefiCpuPkg/ResetVecor/Vtf0 and an IA32/X64 specific feature in the GenFv

Paolo, The SMBASE register is internal and cannot be directly accessed by any CPU. There is an SMBASE field that is member of the SMM Save State area and can only be modified from SMM and requires

I agree, because... that would suggest that matching reset vector code already exists, and it would "only" need to be upstreamed to edk2. :) ( This thread (esp. Jiewen's and Mike's messages) are

The firmware and QEMU could agree on a formula, which would compute the CPU-specific SMBASE from a value pre-programmed by the firmware, and the initial APIC ID of the hot-added CPU. Yes, it would

Yes, that is what I proposed here: * http://mid.mail-archive.com/effa5e32-be1e-4703-4419-8866b7754e2d@... * https://edk2.groups.io/g/devel/message/45570 Namely: (I know that Paolo didn't

Paolo, It makes sense to match real HW. That puts us back to the reset vector and handling the initial SMI at 3000:8000. That is all workable from a FW implementation perspective. It look like the

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)