Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"
Greg Favor
Below are my comments ... On Mon, Aug 1, 2022 at 3:34 AM Guo Ren <guoren@...> wrote: First note that a ratified extension will probably appear in the Priv spec as a separate chapter (as was done with the three Sv* extensions ratified last year), or it might be included as part of the Svpbmt chapter as a separate section. Tbd.
The OR is incorrect. For satp only menvcfg matters. For vsatp both menvcfg AND henvcfg matter - as is the case in general for features in VS/VU modes that are controlled by the *envcfg CSRs.
... is ...
This is only true for 4 KiB pages. What about larger page sizes? This probably needs to be expressed in a manner that is page size agnostic.
... of the leaf PTE ...
Satp does not support this translation mode. And satp is not dependent on menvcfg. (Conversely vsatp is dependent on both memvcfg AND henvcfg.) More generally this whole paragraph seems to either have a number of errors or is poorly worded. Also the intro - that says to consider a system supporting the H extension - would seem to focus in on vstap, but then the paragraph starts talking about satp. It probably would be good to have separate paragraphs for the satp functionality and the vsatp functionality (especially since this extension is not limited to use only in virtualized environments).
Isn't this for without Svpbmt?
By merging PPN[1] and PPN[0], this seems to only apply to 4K leaf PTEs? Is that intended or why the merging? Why the '[2]' suffix to 'MT'? PFN doesn't have such a suffix. Conversely the above PPN's have a suffix to distinguish between the two PPN fields. Greg |
|