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

[Laszlo Ersek <lersek@redhat.com>]

another point:

On 04/22/15 23:41, Laszlo Ersek wrote:
> On 04/21/15 17:04, Gerd Hoffmann wrote:

>>> - can the guest somehow use this facility to detect, dynamically, the
>>> presence of this feature? (For now I'm thinking about a static build
>>> flag for OVMF that would enable SMM support, but I'm 99% sure Jordan
>>> will object and ask for a dynamic feature detection.)
>>
>> Hmm.  I think if we merge all the smm / smram / tseg patches in one go
>> this should work.  Without patches reading the ESMRAMC register returns
>> zero.  With the patches the three cache-disable bits are hardcoded to
>> '1'.  This should work for detecting tseg support.
>>
>> You also have to test for smm support.  The current protocol for this is
>> that seabios checks whenever smm is already initialized (see
>> *_apmc_smm_setup() in seabios/src/fw/smm.c) and if so it skips smm
>> initialization.  Right now qemu sets the bit on reset when running on
>> kvm, so seabios doesn't try to use smm.  On tcg the bit is clear after
>> reset and seabios actually uses smm mode.
> 
> I started looking into this. Basically the condition for SMM/SMRAM
> support is:
> 
>   Q35 && SMRAM support && SMM support           (1)
> 
> The first subcondition can be checked via the host bridge devid (and
> OVMF already does, for other purposes).
> 
> The second one relies on the ESMRAMC, which is in PCI config space.
> 
> The third one is messy. It relies on SMI_EN, which is an ioport at
> PMBA+0x30. It requires a configured PMBA.
> 
> The problem for OVMF is the following: this condition is too complex /
> too intrusive to evaluate in order to see whether Q35+SMM+SMRAM are
> available.
> 
> For that reason, I'd like to ask if it would be possible to introduce a
> new fw_cfg file that would simply communicate the end result of the
> above expression.

There's another problem with basing this decision in OVMF on
SMI_EN.APMC_EN: it is not an idempotent check. At some point the
firmware itself has to set SMI_EN.APMC_EN.

This is probably no issue for SeaBIOS, but in OVMF there's a bunch of
more-or-less independently dispatched modules that depend on condition
(1), and if I set SMI_EN.APMC_EN in some of those modules myself, then
code that ends up running later cannot reuse SMI_EN.APMC_EN for
determining (1). So I'd have to store the original result in some PCD,
but that itself doesn't guarantee ordering either, so it just becomes a
huge mess.

fw_cfg on the other hand is always available, and this fw_cfg file would
never change.

Thanks!
Laszlo