how to understand the PMA and the PBMT?

[rock-ifly]

What is the relationship between the PMA and the PBMT?

1. Is the pma(Cacheable / shareable) necessary? We think the answer is Yes, does it mean any hart must build its own PMA attribute?
2. Are there any principles for building pma in a hart that we should follow?
3. The PMBT seems an enforced PMA for the ordinary PMA. That is to say the PBMT can override the PMA attributes. Even the page is configured with Cacheable(like WBRWA) or Non-Cacheable originally in PMA, the PBMT can set it to be device by the PMBT field in the PTE under the PBMTE=1.
   4）Can we just use the PBMT field as PMA field in the pte, without implementation an common PMA? That is PBMT=0 means Cacheable, PBMT=1 means NC( non-Cacheable), PBMT=2 means IO(nGnRnE).PBMT=3 means page fault. Or the PMA is a MUST, and the PBMT is a suppplement. What is the ordinary/common means for the PMA and the PBMT?

In Sv39, Sv48, and Sv57, bits 62-61 of a leaf page table entry indicate the use of page-based memory types that override the PMA(s) for the associated memory pages.

[aswaterman]

1. Is the pma(Cacheable / shareable) necessary? We think the answer is Yes, does it mean any hart must build its own PMA attribute?

Normally, the answer is yes, they are necessary. Without this PMA, the processor would not know whether a physical-memory access (without PBMT, I mean) could be allocated in cache.

(Obviously, implementations without caches don't need this PMA.)

2. Are there any principles for building pma in a hart that we should follow?

It's hard to know how to answer this question since it is so broad, but one important consideration is that PBMT can only make the attributes stronger; it can't make them weaker. So the PMAs should err on the side of weak. For example, you might define the PMAs for all of main memory to be cacheable, so that PBMT can override subsets of main memory to be NC/IO.

3. The PMBT seems an enforced PMA for the ordinary PMA. That is to say the PBMT can override the PMA attributes. Even the page is configured with Cacheable(like WBRWA) or Non-Cacheable originally in PMA, the PBMT can set it to be device by the PMBT field in the PTE under the PBMTE=1.
   4）Can we just use the PBMT field as PMA field in the pte, without implementation an common PMA? That is PBMT=0 means Cacheable, PBMT=1 means NC( non-Cacheable), PBMT=2 means IO(nGnRnE).PBMT=3 means page fault. Or the PMA is a MUST, and the PBMT is a suppplement. What is the ordinary/common means for the PMA and the PBMT?

PMA is a must, because not all accesses use the page tables. Those untranslated accesses need attributes, too.

[rock-ifly]

1. How to understand the "Both I/O and main memory" for the purposes of FENCE, .aq, and .rl.?
   Does it mean MMU tells the lsu with Both "IO and Non-Cacheable"? So, how to deal with the data, how to keep order if a pte with I/O attribute is force into a pte with non-cacheable by PBMT?

If the underlying physical memory attribute for a page is I/O, and the page has PBMT=NC, then
accesses to that page obey RVWMO. However, accesses to such pages are considered to be both I/O and
main memory accesses for the purposes of FENCE, .aq, and .rl.
If the underlying physical memory attribute for a page is main memory, and the page has PBMT=IO,
then accesses to that page obey strong channel 0 I/O ordering rules. However, accesses to such pages
are considered to be both I/O and main memory accesses for the purposes of FENCE, .aq, and .rl.

2. How to deal with the loss of coherence and memor order? Is there any guide？

Accessing the same location using different attributes that are both non-cacheable (e.g., NC and IO)
does not cause loss of coherence, but might result in weaker memory ordering than the stricter
attribute ordinarily guarantees. Executing a fence iorw, iorw instruction between such accesses
suffices to prevent loss of memory ordering.
Accessing the same location using different cacheability attributes may cause loss of coherence.
Executing the following sequence between such accesses prevents both loss of coherence and loss of
memory ordering: fence iorw, iorw, followed by cbo.flush to an address of that location, followed
by a fence iorw, iorw.

[rock-ifly]

How to define the pma attr when V=1 and pbmte=0

when the V=1, hgatp.mode !=bare, vsatp.mode !=bare, pbmte=0
how to determine the final pma?

1. In some architecture, VS stage memAttr(memory attributes) and G-stage memAttr determine the final memAttr together, choosing the stricter constraints, such as when the memAttr_VS=non-Cacheable and memAttr_G=cacheable, then the final ### memAttr_final = stricter{memAttr_VS, memAttr_G} = non-Cacheable

2. while the RV PBMT spec says that
   when 2a) the V=1, hgatp.mode !=bare, vsatp.mode !=bare, menvcfg.pbmte=1, henvcfg.pbmte=1
   and 2b) pbmt_pte_VS=0, pbmt_pte_G=0,
   and 2c) the memAttr_VS=non-Cacheable and memAttr_G=cacheable,
   then the final ### memAttr_final = memAttr_G = Cacheable

When two-stage address translation is enabled within the H extension, the page-based memory types are also applied in two stages. First, if hgatp.MODE is not equal to zero, non-zero G-stage PTE PBMT bits override the attributes in the PMA to produce an intermediate set of attributes. Otherwise, the PMAs serve as the intermediate attributes. Second, if vsatp.MODE is not equal to zero, non-zero VS-stage PTE PBMT bits override the intermediate attributes to produce the final set of attributes used by
accesses to the page in question. Otherwise, the intermediate attributes are used as the final set of attributes.

[gfavor]

When PBMTE=0 (i.e Svpbmt is disabled and must appear - per the spec - as if it is not implemented), the memory attributes for memory accesses are determined simply (and solely) by the PMAs. And in two-stage address translation, if Svpbmt is not enabled/implemented for a given stage, then the behavior is the same as if you read the spec paragraph about two-stage translation with MODE=0 (i.e. Svpbmt not enabled/implemented has the same effect as Bare mode translation - in both cases actual address translation using page tables is not in effect and hence there is no PTE PBMT field to take into account).

[rock-ifly]

When PBMTE=0 (i.e Svpbmt is disabled and must appear - per the spec - as if it is not implemented), the memory attributes for memory accesses are determined simply (and solely) by the PMAs. And in two-stage address translation, if Svpbmt is not enabled/implemented for a given stage, then the behavior is the same as if you read the spec paragraph about two-stage translation with MODE=0 (i.e. Svpbmt not enabled/implemented has the same effect as Bare mode translation - in both cases actual address translation using page tables is not in effect and hence there is no PTE PBMT field to take into account).

Hi gfavor,

Thank you very much for your kind reply.

When PBMTE=0 (i.e Svpbmt is disabled and must appear - per the spec - as if it is not implemented), the memory attributes for memory accesses are determined simply (and solely) by the PMAs.
----> It is clear that, in one-stage translation, memAttr_final = leafpte_PMA

And in two-stage address translation, if Svpbmt is not enabled/implemented for a given stage, then the behavior is the same as if you read the spec paragraph about two-stage translation with MODE=0 (i.e. Svpbmt not enabled/implemented has the same effect as Bare mode translation - in both cases actual address translation using page tables is not in effect and hence there is no PTE PBMT field to take into account).
---->Q1: I am not clear on this spot. what does the bare mode mean, Q1a or Q1b?
Q1a) vsatp.mode=Bare in VS-stage translation, or just Q1b) the pbmt_pte_VS=0( mean Bare?) ? If the answer is Q1a, why?
---->Q2: when V=1(virutualizeion is running), if menvcfg.pbmte=0, menvcfg.pbmte=1, but per the spec, henvcfg.pbmte is read-only zero. Does it mean Q2a or Q2B?
Q2a）if menvcfg.pbmte=0, then henvcfg.pbmte=0, and all the pbmt_pte_S/VS/G are no longer used,？
Q2b) or the menvcfg.pbmte=0 just make pbmt_pte_G no longer used, and the henvcfg.pbmte=1 make pbmt_pte_VS still be used as usual?

[gfavor]

On Sun, Oct 27, 2024 at 8:55 AM rock-ifly ***@***.***> wrote: And in two-stage address translation, if Svpbmt is not enabled/implemented for a given stage, then the behavior is the same as if you read the spec paragraph about two-stage translation with MODE=0 (i.e. Svpbmt not enabled/implemented has the same effect as *Bare mode translation* - in both cases actual address translation using page tables is not in effect and hence there is no PTE PBMT field to take into account). ---->Q1: I am not clear on this spot. what does the bare mode mean, Q1a or Q1b? Q1a) vsatp.mode=Bare in VS-stage translation, or just Q1b) the pbmt_pte_VS=0( mean Bare?) ? If the answer is Q1a, why? As defined in the Priv spec, *atp.MODE = 0 = "Bare". This applies for all

three *atp CSRs.

---->Q2: when V=1(virutualizeion is running), if menvcfg.pbmte=0, menvcfg.pbmte=1, but per the spec, henvcfg.pbmte is read-only zero. Does it mean Q2a or Q2B? Q2a）if menvcfg.pbmte=0, then henvcfg.pbmte=0, and all the pbmt_pte_S/VS/G are no longer used,？ Q2b) or the menvcfg.pbmte=0 just make pbmt_pte_G no longer used, and the henvcfg.pbmte=1 make pbmt_pte_VS still be used as usual? See the definitions of menvcfg.PBMTE and henvcfg.PBMTE in the Priv spec -

they fully define the effects that each bit has (including answering your question). Note that Q2b directly violates the spec for menvcfg.PBMTE. Message ID: ***@***.***>

…

[rock-ifly]

Hi gfavor,

Thank you very much!

Do you mean
Q1) the PMA are static, or pre-determined by some implementation-dependent micro-architecture registers, and the value of the register can not be changed?
Q2) the PBMT field is used to override the pre-determined PMA in Q1 for every leaf PTE? That is to say, PBMT is the mean to set the PMA page by page, kind of like the mair register in Arm to determine the PMA page by page?
Q3) the PBMTE=0 means xatp.mode=Bare? So
Q3a) if menvcfg.pbmte=1, henvcfg.pbmte=1, works as the last paragraph say in the RISCV Svpbmt spec
Q3b) if menvcfg.pbmte=1, henvcfg.pbmte=0, then S-mode and G-stage can use the pbmt_pte_S/pbmt_pte_G field to get the memAttr, and pbmt_pte_VS MUST be ZERO?
Q3c) if menvcfg.pbmte=0, then henvcfg.pbmte is read only zero and also works as ZERO, making pbmt_pte_VS=0, then this is the same as all three Xatp.mode=Bare? Bare for what, just for the memAttr computation(memAttr=PMA-predefined, tranlation and pte also work), or for the whole address translation(if so, just let pa=va, and no translation works)?

Thanks again!

[chara811]

when V=1, are there 4 types of translation as following?

• VS-stage off, G-stage off, seems wierd
• VS-stage off, G-stage on
• VS-stage on, G-stage off,
• VS-stage on, G-stage on, the common virtualization.

[rock-ifly]

Re-read the spec, it seems that PMA is a more general memAttr configuration, NOT for every page. To specify the memAttr for every single page, PBMT field is introduced. That's to say, PMA is general and configured for a large part of the memory, NOT page by page, while the PBMT is used for every single page since it is in the payload of every leafpte.

1. From a perspective, PBMT is kind of MAIR registers for the ARM architecture. Both the PBMT and AttrIndex(index for MAIR codes) are set page by page.
2. For a more general usage, PBMT fields are commonly used in the translation to get more varieties of the memAttr.

[allenjbaum]

Also: PMA operates even if translation is disabled, There is effectively a PMA for each attribute, each of which can have multiple regions of arbitrary size The PBMT bit in page table entry overrides the corresponding PMA attributes (or leaves them unchanged)

…

On Sun, Oct 27, 2024 at 8:32 PM rock-ifly ***@***.***> wrote: Re-read the spec, it seems that PMA is a more general memAttr configuration, NOT for every page. To specify the memAttr for every single page, PBMT field is introduced. That's to say, PMA is general and configured for a large part of the memory, NOT page by page, while the PBMT is used for every single page since it is in the payload of every leafpte. 1. From a perspective, PBMT is kind of MAIR registers for the ARM architecture. Both the PBMT and AttrIndex(index for MAIR codes) are set page by page. 2. For a more general usage, PBMT fields are commonly used in the translation to get more varieties of the memAttr. — Reply to this email directly, view it on GitHub <#1687 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJWIPDCJNZDJPVS3UZDZ5WV3RAVCNFSM6AAAAABQCUB44OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBQGQ3TQOBWHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rock-ifly]

Also: PMA operates even if translation is disabled, There is effectively a PMA for each attribute, each of which can have multiple regions of arbitrary size The PBMT bit in page table entry overrides the corresponding PMA attributes (or leaves them unchanged)

Hi Allen,

Thank you for your helpful reply. So we just take PMA as a basic configration for the memory space, and use PBMT to describe the PMA attrs per page, and PBMT give a more choice configure the PMA_effective for the page.

I am puzzled by RV spec about two-stage translation, and doubt why PBMTE=0 means corresponding Xatp.MODE=Bare.
Q1) Does it means we should configure menvcfg.pbmte=1 at least when we use two-stage translation?
Q2) Is it a reasonable case when V=1 and menvcfg.pbmte=0(this make henvcfg.pbmte=0, and no pbmt work at pte_VS)? Can two-stage translation works just use the PMA-pre-determined?
Q3) Should we consider all the four cases for implementation? Are they reasonable for the real world?

• Q3a)VS-stage off, G-stage off, seems wierd, but we just get HPA=GPA=GVA, and just use the original PMA
• Q3b)VS-stage off, G-stage on, seems reasonable for GuestOS initialization, GPA=GVA, original PMA, and then GPA is translated into HPA by G-stage translation.
• Q3c)VS-stage on, G-stage off, seems unreasonable, why GuestOS is working while G-stage is off? Can we just get GPA from GVA by VS-stage(with original PMA), and then make HPA=GPA , with original PMA in G-stage(off) translation?
• Q3d)VS-stage on, G-stage on, the common virtualization. works as last paragraph in Svpbmt spec

…
On Sun, Oct 27, 2024 at 8:32 PM rock-ifly @.> wrote: Re-read the spec, it seems that PMA is a more general memAttr configuration, NOT for every page. To specify the memAttr for every single page, PBMT field is introduced. That's to say, PMA is general and configured for a large part of the memory, NOT page by page, while the PBMT is used for every single page since it is in the payload of every leafpte. 1. From a perspective, PBMT is kind of MAIR registers for the ARM architecture. Both the PBMT and AttrIndex(index for MAIR codes) are set page by page. 2. For a more general usage, PBMT fields are commonly used in the translation to get more varieties of the memAttr. — Reply to this email directly, view it on GitHub <#1687 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJWIPDCJNZDJPVS3UZDZ5WV3RAVCNFSM6AAAAABQCUB44OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBQGQ3TQOBWHA . You are receiving this because you are subscribed to this thread.Message ID: @.>

[gfavor]

I am puzzled by RV spec about two-stage translation, and doubt why PBMTE=0 means corresponding Xatp.MODE=Bare.

PBMTE=0 corresponds to *atp.MODE=Bare in that there is no leaf PTE PBMT field to provide any selective override of the PMA attributes. If that is a confusing reference, then it may be better to simply think in terms of PBMTE=0 meaning that there is no override of attributes by the associated translation table. In that sense the effect is the same as if PBMTE=1 and PBMT=0 from the associated translation table leaf PTE. Message ID: ***@***.***>

…

[rock-ifly]

Hi gfavor,

Thanks for your reply. Let's make it clear,

When two-stage address translation is enabled within the H extension, the page-based memory types are also applied in two stages.

It is clear that pbmt works during two stage translation.

First, if hgatp.MODE is not equal to zero, non-zero G-stage PTE PBMT bits override the attributes in the PMA to produce an intermediate set of attributes. Otherwise, the PMAs serve as the intermediate attributes.

Q1) what does "otherwise" mean? Is memAttr_intermediate = G-stage PTE PBMT, override the PMA under the conditionA((hgatp.MODE !=0) & (pbmt_pte_G !=0)), the "otherwise" is ~conditionA, that 's ~conditionA = ((hgatp.MODE=Bare) | (pbmt_pte_G = 0))? So the pmbte=0 means use the original PMA.

Second, if vsatp.MODE is not equal to zero, non-zero VS-stage PTE PBMT bits override the intermediate attributes to produce the final set of attributes used by accesses to the page in question. Otherwise, the intermediate attributes are used as the final set of attributes.

Q2) what does "otherwise" mean? Is memAttr_final = VS-stage PTE PBMT, override the memAttr_intermediate under the conditionB((vsatp.MODE !=0) & (pbmt_pte_VS !=0)), the "otherwise" is ~conditionB, that 's ~conditionB = ((vsatp.MODE=Bare) | (pbmt_pte_VS = 0))? So the henvcfg.pmbte=0 means use the memAttr_intermediate.

Q3) it seems that G-stage have more power to determine the final memAttr. Why can't the GuestOS PMA have more power than G-stage PMA? It seems the right way that GuestOS have more power to control the final memAttr, is it right?

[gfavor]

First, if hgatp.MODE is not equal to zero, non-zero G-stage PTE PBMT bits override the attributes in the PMA to produce an intermediate set of attributes. *Otherwise*, the PMAs serve as the intermediate attributes. Q1) what does "otherwise" mean? This means that if the preceding condition is not true, then the following

statement (that the PMAs serve as the intermediate attributes) applies. Q3) it seems that G-stage have more power to determine the final memAttr.

Why can't the GuestOS PMA have more power than G-stage PMA? It seems the right way that GuestOS have more power to control the final memAttr, is it right?

A VM should see the effective memory attributes based on the actual PMAs as then modified by the hypervisor through G-stage page tables. In other words, the hypervisor determines the memory attributes that a guest sees (and can then further modify via its VS-stage page tables).

[rock-ifly]

So can we get the following rules

1. for one-stage translation

• 1a) if satp.mode =Bare or pbmt_pte_S=0, then memAttr_final = PMA_original
• 1b) if satp.mode!=Bare and pbmt_pte_S !=0, then memAttr_final = pbmt_pte_S (!=0)

2. for two-stage translation

• 2.1 memAttr_interdiate computation
  --2.1a) if hgatp.mode !=Bare and pbmt_pte_G !=0, then memAttr_intermediate = pbmt_pte_G(!=0)
  --2.1b) if hgatp.mode=Bare or pbmt_pte_G=0, then memAttr_intermediate = PMA_original
• 2.2 memAttr_final computation
  --2.2a) if vsatp.mode !=Bare and pbmt_pte_VS !=0，then memAttr_final = pbmt_pte_VS(!=0)
  --2.2b) if vsatp.mode=Bare or pbmt_pte_VS=0, then memAttr_final = memAttr_intermediate

[gfavor]

That is pretty much correct. Just note that PMAs provide a set of memory attributes - some of which are modified by a non-zero PBMT and some are not. Svpbmt specifies the attributes that definitely are modified and then says:

Implementations may override additional PMAs not explicitly listed in Table 27. For example, to be
consistent with the characteristics of a typical I/O region, a misaligned memory access to a page with
PBMT=IO might raise an exception, even if the underlying region were main memory and the same access
would have succeeded for PBMT=PMA.

[rock-ifly]

A VM should see the effective memory attributes based on the actual PMAs as then modified by the hypervisor through G-stage page tables. In other words, the hypervisor determines the memory attributes that a guest sees (and can then further modify via its VS-stage page tables).

I try to understand the logic, since i found the override logic give more power for G-stage(Hypervisor), GuestOS

1. PMA is a static/overall configuration for the whole physical memory system, usually fixed at the beginning of the system boot, and use to configure which part is cacheable, which is NC/IO. For the specified application, PMA is pre-determined for the whole memory, not for every single pte.
2. Yes, PMAs as then modified by the hypervisor through G-stage page tables. This means that G-stage stronger memAttr （NC/IO）can override PMA-predetermined. But how to deal with the opposite cases? like G-stage NC override PMA-predetermined IO, losing the memory order here.
3. GuestOS can further modify via its VS-stage page tables. There are still problems when G-stage is stronger than VS-stage, like G-stage is IO and VS-stage is NC, This rule produce a NC. But as I saw in some processor (ARM cores), the stronger limit are chosen as the final memAttr. I doubt why not use the same logic since the stricter seems a more logical choice.
4. example for the puzzle, different logic produce different results.

• In some architecture(Arm), VS stage memAttr(memory attributes) and G-stage memAttr determine the final memAttr together, choosing the stricter constraints,
  -------such as when the memAttr_VS=non-Cacheable and memAttr_G=nGnRnE,
  -------then the final ### memAttr_final = stricter{memAttr_VS, memAttr_G} = nGnRnE
• according to the RV PBMT spec
  ---------when 2a) the V=1, hgatp.mode !=bare, vsatp.mode !=bare, menvcfg.pbmte=1, henvcfg.pbmte=1
  ---------and 2b) the memAttr_VS=non-Cacheable and memAttr_G=nGnRnE,
  then the final ### memAttr_final = memAttr_VS = non-Cacheable

[gfavor]

Yes, Svpbmt didn't pursue an ARM-like model. But RISC-V and ARM are different in an important regard: 1) ARM doesn't have PMAs and only/always determines memory types from page tables - even in its equivalent of M-mode. In this regard, RISC-V is more like x86 - which has its equivalent of region-based "PMAs" and does not use a strict model of only "strenghthening" a memory type. The details in all this are not so obvious, but were considered at the time of developing this extension. Simply comparing with what ARM did is misleading because of the different underlying architectural situation of having region-based PMAs.

[rock-ifly]

Yes, Svpbmt didn't pursue an ARM-like model. But RISC-V and ARM are different in an important regard: 1) ARM doesn't have PMAs and only/always determines memory types from page tables - even in its equivalent of M-mode. In this regard, RISC-V is more like x86 - which has its equivalent of region-based "PMAs" and does not use a strict model of only "strenghthening" a memory type. The details in all this are not so obvious, but were considered at the time of developing this extension. Simply comparing with what ARM did is misleading because of the different underlying architectural situation of having region-based PMAs.

OK, I need more time to think about it.

Thank you very much for your kindly and helpful reply.

[rock-ifly]

That is pretty much correct. Just note that PMAs provide a set of memory attributes - some of which are modified by a non-zero PBMT and some are not.

So can we get the following rules
for one-stage translation
1a) if satp.mode =Bare or pbmt_pte_S=0, then memAttr_final = PMA_original
1b) if satp.mode!=Bare and pbmt_pte_S !=0, then memAttr_final = pbmt_pte_S (!=0)
for two-stage translation
2.1 memAttr_interdiate computation
--2.1a) if hgatp.mode !=Bare and pbmt_pte_G !=0, then memAttr_intermediate = pbmt_pte_G(!=0)
--2.1b) if hgatp.mode=Bare or pbmt_pte_G=0, then memAttr_intermediate = PMA_original
2.2 memAttr_final computation
--2.2a) if vsatp.mode !=Bare and pbmt_pte_VS !=0，then memAttr_final = pbmt_pte_VS(!=0)
--2.2b) if vsatp.mode=Bare or pbmt_pte_VS=0, then memAttr_final = memAttr_intermediate

Hi gfavor,

I am puzzled with the specific condition when V=1, vsatp.mode=Sv39, pbmt_pte_VS=2b00, hgatp.mode=Bare,

for two-stage translation
2.1 memAttr_interdiate computation
--2.1a) if hgatp.mode !=Bare and pbmt_pte_G !=0, then memAttr_intermediate = pbmt_pte_G(!=0)
--2.1b) if hgatp.mode=Bare or pbmt_pte_G=0, then memAttr_intermediate = PMA_original
Since hgatp.mode=Bare, according to 2.1b, then memAttr_intermediate = PMA_original(system default PMA)
2.2 memAttr_final computation
--2.2a) if vsatp.mode !=Bare and pbmt_pte_VS !=0，then memAttr_final = pbmt_pte_VS(!=0)
--2.2b) if vsatp.mode=Bare or pbmt_pte_VS=0, then memAttr_final = memAttr_intermediate
Since vsatp.mode=Sv39 !=Bare, but pbmt_pte_VS=2b00, then according to 2.2b, memAttr_final = memAttr_intermediate = PMA_original(system default PMA)

Is there something wrong? Since hgatp.mode=Bare, why not just use GuestOS default PMA (PMA_VS-stage) as the memAttr_final?

Thank you.

[gfavor]

PBMT=0 is described as "None", meaning that there are no "requested memory attributes" or, in other words, there is no override of any of the memory attributes. It is not saying that the attributes comes directly from the PMAs.

[rock-ifly]

Q1 - First,

PBMT=0 is described as "None", meaning that there are no "requested memory attributes" or, in other words, there is no override of any of the memory attributes.

So when Pbmt=0 means no override of any memory attributes. Can GuestOS have its own PMA_VS_stage? Can we use the PMA_VS_stage as the final memAttr when hgatp.mode=Bare?

Q2 - Second, we find that linux for RISCV has assigned pte.memAttr=Cacheable when pbmt=2b00. Can we take the cacheable as the final cacheablity when pbmt_pte_vs=2b00, under the condition vstatp.mode=Sv39, pbmt_pte_vs=2b00, hgatp.mode=Bare(flat translation)?

It is not saying that the attributes comes directly from the PMAs.

Q3 - what does your PMAs mean? system predefined PMA(PMA_original), like the SoC system predetermined, or the GuestOS default PMA(PMA_VS_stage), like very system has its own default PMA? Thank you.

[gfavor]

"PMAs" are defined in chapter/section "3.6. Physical Memory Attributes" of the Priv spec.

There are no other "PMAs" in he RISC-V architecture that belong to any specific privilege level or translation mode or stage of translation. There are just the one and only preceding PMAs. Single and two-stage translation can modify (aka override) selected physical memory attributes through use of the Svpbmt extension.

Regarding Q2, if the PMAs for an address specify the Cacheable attribute and there is no override of that by a leaf PTE, then - as defined by the Svpbmt extension - the final effective attribute is Cacheable. (And this is orthogonal to the translation MODE(s) in effect for translating that address.)