
82815 GMCH
R
126
Datasheet
TSEG
TSEG can be up to 1 MB and is at the top of memory. SMM-mode processor accesses to enabled TSEG
access the physical DRAM at the same address. Non-SMM-mode processor accesses to enabled TSEG
are considered invalid and are terminated immediately on the FSB. The exception is non-SMM-mode
write-back cycles. They are directed to the physical SMM space to maintain cache coherency. AGP and
hub interface originated cycle to enabled SMM space are not allowed.
The size of the SMRAM space is determined by the USMM value in the SMRAM register. When the
extended SMRAM space is enabled, non-SMM processor accesses and all other accesses in this range
are forwarded to the hub interface. When SMM is enabled, the amount of memory available to the
system is equal to the amount of physical DRAM minus the value in the TSEG register.
Note that there is potential for cache corruption if illegal accesses are requested to TSEG. Originally,
TSEG was intended for additional data storage for non-cached solutions. As such, it added protection as
direct reads and writes to TSEG are not allowed to occur outside of SMM. However, when the region is
enabled as cacheable, this protection can cause problems if improperly used. The reason is that, if any
piece of software (including ITP) is to read TSEG outside of SMM, the read can cause corruption of the
cached version of the code in the processor and result in a SMM “hang”.
Example of Problem Manifestation:
1. SMM handler initialized and SMM code/data is written to TSEG
2. Processor cache emptied of TSEG data sometime later as cache lines are evicted and replaced
3. Rogue application requests illegal memory read to TSEG (illegal because processor is not in
SMM)
4. Processor runs memory read cycles to GMCH to perform read from TSEG
5. GMCH realizes processor is NOT in SMM and blocks the reads from targeting actual memory.
Instead it runs the cycle down the hub interface, which ICH2 then converts to a PCI cycle. This
typically gets master aborted and returns a floating bus (FFFFFFFFh).
6. Processor read cycles complete and FFFFFFFFh is pulled into processor cache lines.
7. Processor thinks it has valid TSEG code/data in its cache, when it really has incorrect data
(FFFFFFFFh)
8. Processor runs other system level code, evicting cache lines as needed, but some lines of
FFFFFFFFh remain
9. Eventually, an SMI is generated and this puts the processor into SMM and calls for execution of
the SMM handler stored in TSEG.
10. Processor begins fetching TSEG and hits a line in its cache read by the rogue application
(FFFFFFFFh).
11. This code is corrupted and a “hang” is eminent
The result is that the TSEG protection built into the chipset could potentially cause a system to “hang”
for cached operations, if not properly used. In fact, an application that only reads from the TSEG region
can cause SMRAM corruption by causing the SMM handler to execute bogus code fetched from the PCI
bus.
An alternative is to not use TSEG chipset features at all when running cached. Simply reserve a piece of
system memory at the top of memory region, indicate a lower actual top of memory to the operating
system (through E820h/E801h function calls), and use this region as SMRAM. As there is no restriction
that this memory cannot be accessed when not in SMM mode, then the GMCH will not block accesses to
it. When it is cached, a read to the region (whether performed inside or outside of SMRAM) will return
the correct data and this coherency issue is avoided.