cedarhouse1@comcast.net has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37990 )
Change subject: soc/intel: Add get_pmbase ......................................................................
Patch Set 3:
(1 comment)
This response generally deals with how the STM handles with changes in access.
If there are any questions on this response, please let me know.
https://review.coreboot.org/c/coreboot/+/37990/3//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/37990/3//COMMIT_MSG@14 PS3, Line 14: SMI handler
in SMI handlers it does not seem like a good idea to use a hardcoded value, but to use the one fetch […]
Short answer - the pmbase can be changed later but you might have to tell the STM to allow access.
Long answer - As noted in the commit message, this value has to be in the BIOS resource so that the STM will allow the SMI handler to access the location represented by the pmbase value.
If the pmbase value is changed and the SMI Handler attempts to access this area, there are three possible scenarios: (1) the resource is claimed by the BIOS, (2) the resource is claimed by the OS and (3) the resource is unclaimed by either the BIOS or the OS.
(1) Since the BIOS has claimed the area, the attempted access by the SMI handler is allowed.
(2) If the O/S has claimed the area and has restricted access such that the SMI hander cannot access the area, then bad things happen as the SMI handler will not be allowed access. In the instance, if the OS changes the pmbase then it needs to tell the STM that the SMI handler is allowed access to this new area. NOTE: the O/S implementer should have gotten this correct during testing.
(3) If the resource is unclaimed, then the STM will grant the access to the SMI handler and generate a log message that the event happened.
Review: the BIOS resource list is the set of resources that the BIOS is claiming for the SMI handler. The operating system can also tell the STM the resources that it does not want the SMI handler to access. However, the operating system cannot override the list that the BIOS has generated. In the case of a conflict, the STM will generate an error message concerning the conflict giving the OS implementer, etc. a chance of deal with the conflict. Finally, the SMI handler is granted access to any resources that have not been claimed by the OS.