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

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

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)

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

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

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

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

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

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

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

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

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]

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

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

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

Paolo, It is my understanding that real HW hot plug uses the SDM defined methods. Meaning the initial SMI is to 3000:8000 and they rebase to TSEG in the first SMI. They must have chipset specific

Paolo, I find the following links related to the discussions here along with one example feature called

Thank you Mike! That is good reference on the real hardware behavior. (Glad it is public.) For threat model, the unique part in virtual environment is temp RAM. The temp RAM in real platform is per

(1) Sorry, my _DMA quote was a detour from QEMU -- I wondered how a physical machine with actual RAM at 0x30000, and also chipset level protection against DMA to/from that RAM range, would expose the

Hi Jiewen, If a hot add CPU needs to run any code before the first SMI, I would recommend is only executes code from a write protected FLASH range without a stack and then wait for the first