----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3401/#review8249 -----------------------------------------------------------
This solution seems very sketchy to me. I would not be surprised if the current code is broken, but I doubt this is the proper fix. Although I don't see where the AMD manual says it explicitly, I expect that the result of adding a new mapping at a larger size without invalidating possible smaller mappings out of the TLB first would be undefined behavior. I'll claim that, if you are really seeing two conflicting mappings being added to the TLB, then either (1) there's a prior TLB invalidation that wasn't handled properly or (2) the OS is broken. I'd put my money on the former. I noticed that there are several cases that are supposed to implicitly invalidate the entire TLB (from section 5.5.2 "TLB Management" of Vol. 2 of the AMD64 manual set). I wonder if we are missing some of these? TLB entries can be explicitly invalidated using operations intended for that purpose or implicitly invalidated as a result of another operation. TLB invalidation has no effect on the associated page-translation tables in memory. **Explicit Invalidations.** Three mechanisms are provided to explicitly invalidate the TLB: • The invalidate TLB entry instruction (INVLPG) can be used to invalidate specific entries within the TLB. This instruction invalidates a page, regardless of whether it is marked as global or not. The Invalidate TLB entry in a Specified ASID (INVLPGA) operates similarly, but operates on the specified ASID. See “Invalidate Page, Alternate ASID” on page 474. • Updates to the CR3 register cause the entire TLB to be invalidated except for global pages. The CR3 register can be updated with the MOV CR3 instruction. CR3 is also updated during a task switch, with the updated CR3 value read from the TSS of the new task. • The TLB_CONTROL field of a VMCB can request specific flushes of the TLB to occur when the VMRUN instruction is executed on that VMCB. See “TLB Flush” on page 473. **Implicit Invalidations.** The following operations cause the entire TLB to be invalidated, including global pages: • Modifying the CR0.PG bit (paging enable). • Modifying the CR4.PAE bit (physical-address extensions), the CR4.PSE bit (page-size extensions), or the CR4.PGE bit (page-global enable). • Entering SMM as a result of an SMI interrupt. • Executing the RSM instruction to return from SMM. • Updating a memory-type range register (MTRR) with the WRMSR instruction. • External initialization of the processor. • External masking of the A20 address bit (asserting the A20M# input signal). • Writes to certain model-specific registers with the WRMSR instruction; see the BIOS and Kernel Developer's Guide applicable to your product for more information - Steve Reinhardt On April 13, 2016, 6:37 a.m., Bjoern A. Zeeb wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3401/ > ----------------------------------------------------------- > > (Updated April 13, 2016, 6:37 a.m.) > > > Review request for Default, Jason Lowe-Power and Steve Reinhardt. > > > Repository: gem5 > > > Description > ------- > > Changeset 11369:52df7c56508b > --------------------------- > x86: fix TLB issue > > In case we have a 4k page mapping and we will later add a 2M > mapping at the same address, we will return the still existing > 4k entry. It is unclear to me why this is, but by deleting any > entry at the same address with a different size we avoid this problem. > > > Diffs > ----- > > src/arch/x86/tlb.cc 2fd64ea0a7cb > > Diff: http://reviews.gem5.org/r/3401/diff/ > > > Testing > ------- > > Observed booting FreeBSD amd64; did a manual run to dump the trie to verify > a few weeks back. > > > Thanks, > > Bjoern A. Zeeb > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
