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
