On 04/21/15 16:38, Paolo Bonzini wrote: > > > On 21/04/2015 16:30, Laszlo Ersek wrote: >>>> - MemoryRegion tseg_blackhole; >>>> + MemoryRegion tseg_blackhole, tseg_window; >>>> PcPciInfo pci_info; >>>> ram_addr_t below_4g_mem_size; >>>> ram_addr_t above_4g_mem_size; >>>> >> Why is this necessary? If you disable the black hole overlay, the access >> will go to the RAM. (Or can't that be done per-CPU?) > > The reason to have two separate MemoryRegions is exactly to allow > per-CPU access. > > tseg_blackhole is added on top of address_space_memory to hide TSEG; > tseg_window is included in /machine/smram and TCG adds it to the private > per-CPU address space when it enters system management mode.
Hm, I must have missed this (or not seen it at all) -- should I have noticed it in Gerd's series somewhere (or in yours)? Or is that by virtue of mapping mch->tseg_window as a subregion of mch->smram? (These overlays are pretty confusing, without a graphical visualization :)) >> I'm thinking, the last 1 / 2 / 8 megabytes should behave as RAM in all >> of the following cases: >> - no SMRAM programmed (tseg size = 0) >> - SMRAM programmed (tseg size > 0), and it is open >> - SMRAM programmed (tseg size > 0) and closed, but CPU in SMM > > Correct. However, you can have one CPU in SMM and another executing > "normal" code. It would be a hole to allow that CPU to read (or worse, > write) the TSEG or legacy SMRAM areas. > >> ... Another question, related to SMM (but not related to SMRAM): Paolo, >> am I right to think that we'll be keying off at least two independent >> things of SMM-or-not: one is access to SMRAM (tseg), for LockBox and SMM >> driver purposes, the other is pflash access (with the MemTxAttrs thing), >> for the varstore? > > Yes. Great, thank you. Yet another question -- as far as I understand, I should have enough info (with my pending questions of course) for EFI_SMM_ACCESS2_PROTOCOL. I've now reviewed EFI_SMM_CONTROL2_PROTOCOL too, and AFAICS the only thing I need to know for it is "how to raise an SMI, synchronously". What are the plans for that? An ioport write perhaps? (I skimmed the ICH9 spec, but whatever I found seemed to be quite inappropriate.) Thanks Laszlo