samcro...@gmail.com wrote: > Yeah, the project is pretty hacky, to be frank, and will be limited to > the setup where SMRAM is from a0000h to bffffh.
That still covers lots of real hardware. > Yes, I'm aware of coreboot's stance on SMM. If I recall correctly, > QEMU seemed to have trouble clearing the SMI_STS register. There's not much reason for QEMU to use SMM, so it may not have a full or even working emulation. > We will likely use hardware to test the setup. You're confirming my fear > related to testing SMM in QEMU. I hope we will be able to see more > SMM activity on a real board, but I don't know what to expect, as I > have trouble finding sources that discuss how SMM is used in the > "wild" (besides articles on reversing and exploiting SMM). I think you'll find (much) more SMM activity on hardware. A few examples: * Legacy keyboard controller emulation for USB keyboards by BIOS You can verify this by letting the BIOS boot some program that never uses interrupts to interact with the keyboard, but exclusively direct IO around port 60h, and perhaps interrupt 1. * "VSA" on Geode platforms emulate entire PCI devices using SMM. * Look for SMM usage in ACPI, especially common for embedded controllers in laptops. > Are you aware whether SMM is tested (for new functionality, for instance), > and if so, how that is being done? Or is this done by using existing > hardware setups? I do not have a lot of experience with low-level hardware. To firmware developers, coreboot at least, I would argue that SMM is seen mostly as a neccessary evil, both because it's cumbersome to deal with, because it interferes with a "clean" system and because it's a matter of fact over which firmware developers have no control. Platform vendors' hardware design decisions drive the SMM requirements for firmware, seemingly with increasing tendency over time. //Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
