Question about virtual address forwarding failure mentioned in LDQ

[Heresyrac]

文档中有提到说在很罕见的情况下会发现在数据前递时虚地址和实地址会匹配到不同的项，此时认为存在前递失败，因此需要进行重定向。
但是到底是怎样的一种罕见情况下会出现这种前递失败呢，文档里好像没有说明？当虚实地址的映射关系改变的时候难道不会清空store buffer/store Queue吗？能否具体说明一下？

[TRANSLATION]
The documentation mentions that in rare cases, the virtual address and the real address match different items during data forwarding, in which case a forwarding failure is considered and a redirect is required.

But what is the rare case in which this lookahead fails, and it doesn't seem to be documented? Doesn't it clear the store buffer/store Queue when the mapping between real and virtual addresses changes? Can you explain it in detail?

[AugustusWillisWang]

当两个虚地址同时映射到同一个实地址时，如果对这两个虚地址的写同时存在于 sq/sbuffer，前递就会出现这样的问题。

当虚实地址的映射关系改变的时候难道不会清空store buffer/store Queue吗？能否具体说明一下？

在用 store 指令更新页表时，硬件不会自动刷新 store buffer/store Queue。只有 SFENCE，satp 寄存器写等操作会触发 store buffer/store Queue 刷新。

[TRANSLATION]
When two virtual addresses are mapped to the same real address at the same time, such problems arise in look-ahead if writes to both virtual addresses exist in sq/ Sbuffers.

Doesn't it clear the store buffer/store Queue when the mapping between real and virtual addresses changes? Can you explain it in detail?

When a page table is updated with a store instruction, the hardware does not automatically flush the store buffer/store Queue. Only SFENCE, operations such as satp register writes trigger store buffer/store Queue flusher.

[Heresyrac]

当两个虚地址同时映射到同一个实地址时，如果对这两个虚地址的写同时存在于 sq/sbuffer，前递就会出现这样的问题。

当虚实地址的映射关系改变的时候难道不会清空store buffer/store Queue吗？能否具体说明一下？

在用 store 指令更新页表时，硬件不会自动刷新 store buffer/store Queue。只有 SFENCE，satp 寄存器写等操作会触发 store buffer/store Queue 刷新。

请问这个意思是说，一个进程中的页表里是确实把多个虚地址映射到了同一个实地址导致了这种情况；还是说，store修改后一个进程里的映射关系仍然是一对一的，但在修改被mmu观察到的那一刻，前后的store的映射出现了不一致？

[TRANSLATION]
Does this mean that the page tables in a process actually map multiple virtual addresses to the same real address? Or is the mapping still one-to-one in the process after a store change, but inconsistent at the moment the change is observed by the mmu?

[AugustusWillisWang]

都有可能 ：）

[Translation]
Both are possible :)

[Heresyrac]

都有可能 ：）

[Translation]
Both are possible :)

了解了。那么可以认为除此以外，没有其他的可能导致这种不一致的情况了吗？

[Translation]
Got it. So can it be assumed that there are no other circumstances that could have caused such inconsistencies?

[AugustusWillisWang]

都有可能 ：）

[Translation]
Both are possible :)

了解了。那么可以认为除此以外，没有其他的可能导致这种不一致的情况了吗？

[Translation]
Got it. So can it be assumed that there are no other circumstances that could have caused such inconsistencies?

是的。

[Translation]
Yes.

[Heresyrac]

都有可能 ：）

[Translation]
Both are possible :)

了解了。那么可以认为除此以外，没有其他的可能导致这种不一致的情况了吗？

[Translation]
Got it. So can it be assumed that there are no other circumstances that could have caused such inconsistencies?

是的。

[Translation]
Yes.

明白了，感谢解答

[Translation]
I understand now. Thanks.

[Heresyrac]

都有可能 ：）

[Translation]
Both are possible :)

了解了。那么可以认为除此以外，没有其他的可能导致这种不一致的情况了吗？

[Translation]
Got it. So can it be assumed that there are no other circumstances that could have caused such inconsistencies?

是的。

[Translation]
Yes.

关于这个我还想请问一个问题，有没有可能由于store修改了页表，导致之后流水线或者队列中的同时存在的两条指令，出现虚地址相同实地址不同的情况？
比如说有指令a store PTE b: store 1->x, c: store->x d: load x->，然后bcd三条都还没有提交. b取物理地址的时候读到了tlb中旧的页表内容，而在c和b中间的某个时刻，x的地址代换被tlb换出了，然后c执行的时候，ptw读到了新的页表内容，导致bc的物理地址不同？
另外d检查前递的时候，能否只检查实地址？

[TRANSLATION]
About this, I would like to ask a question. Is it possible that due to the modification of the page table by the store, two instructions in the pipeline or queue at the same time may have the same virtual address and different real address?

For example, a store PTE b: store 1->x, c: store->x d: b read the old page table contents in tlb when it fetched the physical address, and at some point between c and b, the address of x was swapped out by tlb, and then when c executed, ptw read the new page table contents, resulting in a different physical address for bc?

In addition, can d only check the real address when checking the forward?