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

Reply via email to