Re: [Qemu-devel] [PATCH 6/6] [wip] tseg, part2, not (yet) tested

[Laszlo Ersek <lersek@redhat.com>]

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