Re: Fast-track extension proposal V2 for "Sv32 Svpbmt"
Greg Favor
On Tue, Aug 2, 2022 at 4:48 AM Guo Ren <guoren@...> wrote: >> and Hypervisor Extension (Chapter~\ref{hypervisor}). When satp.mode is Sv32x4 Yes. The Svpbmt32 extension adds Svpbmt The more proper way to say this is that PBMT support is being added (versus saying that an existing extension is being added). (Chapter~\ref{svpbmt}) support to Maybe say "... to allow use of the two highest bits instead as PBMT bits." . The S-mode and Maybe say "... controlled by henvcfg.PBMTE and indirectly also menvcfg.PBMTE."
It would be better to describe this in the same way as the existing PBMTE description, i.e. "When menvcfg.PBMTE=1,
Svpbmt32 is available for S-mode and G-stage address translation." Ultimately these statements will need to be incorporated into the two existing PBMTE descriptions (for menvcfg and henvcfg), but in the meantime one should use the same wording as the existing descriptions. When vsatp.mode is Sv32 and henvcfg.PBMTE set, guest virtual Same comment as above. Sv32 physical address with Svpbmt: I assume the preceding should be 'Svpbmt32'. | 31 30 | 29 20 | 19 10 | 9 8 | 7 | 6 | 5 What does 'PFN' stand for? But more importantly why change names from PPN to PFN (versus maintaining the same naming as in the existing spec)? Especially since PFN[0] is the same as PPN[0], and PFN[1] is just a smaller version of PPN[1]. Greg
|
|