Question about "is_exec" & "priv" in ref model

[hsxyb]

1. for “is_exec” in https://github.com/riscv-non-isa/riscv-iommu/blob/1ab22196074b110c2a5aa124f4993fef90e0b926/iommu_ref_model/libiommu/src/iommu_translate.c#L94 .

it has to be "is_read && req->exec_req". is this a software constraint or hardware constraint that the request has to be a read? .Although it's unlikely, but if iommu receives a write/amo request with a execute req(for example, a write/atomic transaction with awprot[2]==1 using axi protocal), does iommu need to check X permission？

2. for "priv" in https://github.com/riscv-non-isa/riscv-iommu/blob/1ab22196074b110c2a5aa124f4993fef90e0b926/iommu_ref_model/libiommu/src/iommu_translate.c#L96 .

it has to be "req->pid_valid && req->priv_req", is this a software constraint or hardware constraint that the request has to be pid_valid?does hardware need to consider both pid_valid & priv_req to decide whether it is requesting supervisor privilege?

[ved-rivos]

it has to be "is_read && req->exec_req". is this a software constraint or hardware constraint that the request has to be a read?

Instructions are read so that they can be executed. I am not aware of a write-semantics for instructions. This is a hardware constraint.

it has to be "req->pid_valid && req->priv_req", is this a software constraint or hardware constraint that the request has to be pid_valid?does hardware need to consider both pid_valid & priv_req to decide whether it is requesting supervisor privilege?

For G-stage address translation and protection, all memory accesses are treated as unprivilged. This is a hardware constraint.

[baimengwei]

But why there is a constraint about req->tr.at == ADDR_TYPE_UNTRANSLATED || req->pid_valid ?

    is_exec = ( (is_read && req->exec_req &&
                (req->tr.at == ADDR_TYPE_UNTRANSLATED || req->pid_valid)) ) ? 1 : 0;

Does req->pid_valid == 0 can equal to a G-stage address translation ? Why not DC.iohgatp.mode !=Bare equal to a G-stage address translation ?

    priv = ( req->pid_valid && req->priv_req ) ? S_MODE : U_MODE;

[ved-rivos]

But why there is a constraint about req->tr.at == ADDR_TYPE_UNTRANSLATED || req->pid_valid ?

Translated and Translation requests can request execute permission only when there is a PASID TLP prefix i.e. process ID is valid.

Does req->pid_valid == 0 can equal to a G-stage address translation ? Why not DC.iohgatp.mode !=Bare equal to a G-stage address translation ?

G-stage address translation may be Bare or not Bare irrespective of whether the request is to a process address space i.e. process ID is valid. Privilege based separation - user vs. supervisor - is valid only when process based isolation is used i.e. process ID is valid.