Another thing to notice is that the current PCID change is intended for SE mode only (as you might have seen in the comments of the JIRA issue: https://gem5.atlassian.net/browse/GEM5-332). So, the global bit probably would not be used anyways.
-Ayaz On Wed, Feb 1, 2023 at 4:14 PM Ayaz Akram <yazak...@ucdavis.edu> wrote: > Hi Soramichi, > > I agree with the change you are proposing. > > May I open an issue on Jira on this and assign myself? > > > Yes, please do that. > > -Ayaz > > On Tue, Jan 31, 2023 at 11:07 PM Soramichi Akiyama < > s-a...@fc.ritsumei.ac.jp> wrote: > >> Hi Ayaz, >> >> thank you for your reply and I really appreciate your effort for making >> SMT work. >> >> As far as I understand, the stackoverflow entry you mentioned assumes >> that every process uses the same PTE for the same vaddr if there is one >> with global = 1. >> (I am not sure if this is correct as the manual says the processor "may" >> use it, implying that it can choose NOT to use it depending on some other >> conditions.) >> >> In terms of the gem5 code, what I think should be done is: >> 1. Copy the global bit of a PTE to the corresponding TLB entry in >> TLB::insert. >> 2. In TLB::translate, search the TLB with the bare vaddr (with PCID not >> concatenated). >> 3-A. If the found TLB entry's global bit is 1, use it even if CR4.pcide >> is 1. >> 3-B. If the found TLB entry's global bit is 0 and CR4.pcide is 1, compare >> the PCID associated with the found TLB entry with the current process to >> decide whether it should be used. >> >> May I open an issue on Jira on this and assign myself? I think I have a >> somewhat clear plan on how the code should be changed, but the contributing >> guide says it is better to ask a developer for advise. >> >> Best regards, >> >> Soramichi >> >> >> On 2023/01/31 4:39, Ayaz Akram wrote: >> > Hi Soramichi, >> > >> > We recently added the concatenation change to distinguish TLB entries of >> > different processes to make SMT work. You can check more details here: >> > >> > https://gem5.atlassian.net/browse/GEM5-332 >> > >> > I am not sure what the behavior should be for global pages. From some >> > discussion here: >> > >> https://stackoverflow.com/questions/41986862/x86-64-page-table-global-bit >> , >> > it seems we should have the option to flag a TLB entry as a global >> entry. >> > >> > -Ayaz >> > >> > On Sat, Jan 28, 2023 at 1:04 AM Soramichi Akiyama via gem5-users < >> > gem5-users@gem5.org> wrote: >> > >> >> Hello, >> >> >> >> I am trying something related to the global bit of a TLB entry and >> found >> >> that the gem5 code might have inconsistency with the Intel manual. >> >> >> >> The Intel manual says that >> >> "a logical processor may use a global TLB entry to translate a linear >> >> address, >> >> even if the TLB entry is associated with a PCID different from the >> current >> >> PCID". >> >> >> >> However in TLB::translate(), gem5 concatenates the PCID to the vaddr >> when >> >> CR4.pcide >> >> is true and lookup the trie containing the TLB entries using [vaddr + >> PCID] >> >> without considering the global bits of the entries. >> >> >> >> Is the gem5 behavior a bug, or is it a subset of allowed behaviors? >> >> I guess it depends on what the word "may" in the manual means, but not >> >> quite sure. >> >> >> >> Best regards, >> >> >> >> Soramichi Akiyama >> >> _______________________________________________ >> >> gem5-users mailing list -- gem5-users@gem5.org >> >> To unsubscribe send an email to gem5-users-le...@gem5.org >> >> >> > >> >
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
