qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested
Date: Thu, 23 Apr 2015 12:27:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


On 23/04/2015 09:02, Gerd Hoffmann wrote:
>>> > > The third one is messy. It relies on SMI_EN, which is an ioport at
>>> > > PMBA+0x30. It requires a configured PMBA.
> Isn't that initialized early anyway, because the pm timer lives there?
> It's not a regular pci bar exactly to allow early init, so the full pci
> bus scan + bar allocation done later will not mess up things.
> 
> [ just a question, could very well be that even when initialized early
>   it isn't early enough because you need to know the memory layout
>   before uncompressing the firmware modules ]

The nice thing about TSEG is that it's just normal RAM until you lock
it.  So you can add a HOB very early that reserves that memory, and only
later decide whether to use "real" SMM, or just not lock TSEG and jump
into the SMM handler.  (This would be the "experimentation" setting you
were talking about earlier; it would also be used if TSEG is not available).

The fake path would also be used on PIIX.  This means you would _always_
use the SMM stack, even if it's not running in SMM, and you could e.g.
get rid of the PEI/DXE drivers for flash access.

>> > 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.
> Yep, you'll need some variable saying whenever smm is there or not and
> check that.  Because of this.  Or (in case we are going for the fw_cfg
> file) because you don't want dig into fw_cfg each time you need to know
> this.

You can assume that either all of TSEG/SMM/outb(0xb2)/GLB_SMI_EN are
available, or none is.  Detection can go like this:

1) if APMC_EN = 0, SMM is available but other features might not be.
Set APMC_EN and GLB_SMI_EN, set SMI_LOCK(*), then clear GLB_SMI_EN.  Now
APMC_EN is always 1, but a new QEMU won't let you clear GLB_SMI_EN.

        (*) SMI_LOCK is in the configuration space of
            device 31 function 0 (byte 0xa0, bit 4)

2) is GLB_SMI_EN = 1?  Then SMM is available.

3) else, QEMU has set APMC_EN to communicate that SMIs are not
available, or SMIs are available (e.g. old QEMU with TCG) but you don't
have TSEG.  Proceed with fake SMM.

Would this work?  It is idempotent at least.  Even if the OS tries to
maliciously set APMC_EN to 0 (SMI_LOCK doesn't lock APMC_EN), the result
after step 1 is always going to be the same: APMC_EN=GLB_SMI_EN=1 on new
QEMU, APMC_EN=1/GLB_SMI_EN=0 on old QEMU.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]