may cbo.flush on non-cacheable memory raise an exception ?

[Adnan Hamid]

If a cbo.flush is executed on an address that is NOT cachable / does not support Cacheablity PMA, 

1. MAY a RISCV complaint implementation choose to raise an exception ?

2. MUST a RISCV complaint implementation raise an exception ?

From priv spec 3.6 Physical Memory Attributes

"To aid in system debugging, we strongly recommend that, where possible, RISC-
V processors precisely trap physical memory accesses that fail PMA checks."

From priv spec 3.6.5 Coherence and Cacheability PMAs

"The cacheability of a memory region should not affect the software view of the region except for differences reflected in other PMAs,"

[Allen Baum]

Unless the cacheability PMA (or some other) specifically calls out that CBOflush to an uncacheable region will cause a trap,

my reading of (just) the above is that sec3.6.5 says it should not trap (i.e, it's a nop).

I don't trust my reading of this, except how the phrase

   "If a PMA indicates non-cacheability, then accesses to that region must be satisfied by the memory itself, not by any caches."

For implementations with a cacheability-control mechanism, the situation may arise that a program uncacheably accesses a memory location that is currently cache-resident. 

In this situation, the cached copy must be ignored.

I interpret that as a Flush to an address that is treated as uncacheable is identical to a flush to an address that is cacheable, but not cache resident

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/ca1b3bf5-6097-4094-8148-f0f824e696a2n%40groups.riscv.org.

[Adnan Hamid]

Some background on where my questions are coming from:

As vice-chair of the RVI certification steering committee (CSC) test and models working group, one issue I have been working on is establishing a forum where CSC can get definitive guidance when questions come up on how the specification is to be interpreted. So far the consensus has been to come to this forum for these questions.

Meanwhile in my day job as a RISCV test vendor my team  gets a lot of real world customer questions on how to interpret the ISA spec. The answers for some of these questions are not obvious, at least to my team.

We are using some of those questions to get the flow for definitive guidance going.

May we get definitive guidance on the following two questions, restated below:

If a cbo.flush is executed on an address that is NOT cachable / does not support Cacheablity PMA, 

1. MAY a RISCV complaint implementation choose to raise an exception ?

    my opinion: NO, but I don't know how to justify that

2. MUST a RISCV complaint implementation raise an exception ?

    my opinion: NO, mostly because across 20 RISCV commercial implementations, ARM and x86 we have not observed an implementation do this.

Who is authorized to provide definitive definitive guidance in interpreting the ISA ?

-adnan

[Philipp Tomsich]

On Mon 24. Feb 2025 at 05:52, 'Allen Baum' via RISC-V ISA Dev <isa...@groups.riscv.org> wrote:

Unless the cacheability PMA (or some other) specifically calls out that CBOflush to an uncacheable region will cause a trap,

my reading of (just) the above is that sec3.6.5 says it should not trap (i.e, it's a nop).

My reading (and general software practice) suggest the same: if memory is uncached or write-through, cbo.flush will not have an effect by complete normally.  Exceptions are raised for access violations only.

To take this thinking even further, consider the case where cbo.flush is called on a line that is either not currently in the cache or is not dirty: we also wouldn’t consider to raise diagnostics for such a case…

I don't trust my reading of this, except how the phrase

   "If a PMA indicates non-cacheability, then accesses to that region must be satisfied by the memory itself, not by any caches."

For implementations with a cacheability-control mechanism, the situation may arise that a program uncacheably accesses a memory location that is currently cache-resident. 

In this situation, the cached copy must be ignored.

I interpret that as a Flush to an address that is treated as uncacheable is identical to a flush to an address that is cacheable, but not cache resident

On Sat, Feb 22, 2025 at 12:04 PM Adnan Hamid <adnan....@gmail.com> wrote:

If a cbo.flush is executed on an address that is NOT cachable / does not support Cacheablity PMA, 

1. MAY a RISCV complaint implementation choose to raise an exception ?

2. MUST a RISCV complaint implementation raise an exception ?

From priv spec 3.6 Physical Memory Attributes

"To aid in system debugging, we strongly recommend that, where possible, RISC-
V processors precisely trap physical memory accesses that fail PMA checks."

From priv spec 3.6.5 Coherence and Cacheability PMAs

"The cacheability of a memory region should not affect the software view of the region except for differences reflected in other PMAs,"

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/ca1b3bf5-6097-4094-8148-f0f824e696a2n%40groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DDuhQfZBbsAKyhQocmX9eG_m8ZZq2nCXaR7KDKqU3%2Bfrg%40mail.gmail.com.

[Adnan Hamid]

Hi Philipp,

As Vice Chair of the RISCV Technical Steering Committee we accept your response as definitive.

We will point the customer at this thread.

Thank you,

-adnan

[Guy Lemieux]

I would go a bit further than what has been implied by Allen or Philippe:

CBO.FLUSH must flush the address provided from caches independently of
whether or not the region is cacheable. It should only raise an
exception if configured to do so by xenvcfg CSRs, otherwise it should
do the requested flush. In particular, it should not raise an
exception if the memory region is not cacheable.

Rationale: the cacheability property can be dynamic (eg, page table
entry property). Making something uncacheable ensures the access goes
completely to memory and bypasses any caches, but does not remove the
contents from the caches. Executing a CBO.FLUSH should always flush
the data from these caches independent of the current cacheability
setting. That is, it should ensure that the flushed data is no longer
in the caches to plug the security hole that may arise when that
cacheability changes and the stale data is accessed.

> To view this discussion visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DDuhQfZBbsAKyhQocmX9eG_m8ZZq2nCXaR7KDKqU3%2Bfrg%40mail.gmail.com.

[Adnan Hamid]

Thank you for the follow up Guy.

For now we are assuming that any member of the TSC (RISCV Technical Steering Committee) is an authority and can provide definitive guidance on the specification.

-adnan

[Greg Favor]

On Mon, Mar 3, 2025 at 9:53 AM Adnan Hamid <adnan....@gmail.com> wrote:

Thank you for the follow up Guy.

For now we are assuming that any member of the TSC (RISCV Technical Steering Committee) is an authority and can provide definitive guidance on the specification.

-adnan

I agree with the conclusions that have been reached in this thread, but I should note that the chairs of the TSC do NOT possess any special or greater weight in interpreting the arch specs.  Ultimately, if there is contention over the interpretation of an arch extension, the first point of resolution would be the TG and its chairs that developed the extension.  Barring that (e.g. the TG has long ago come and gone), then the ARC would be the second point of resolution.

But in this case I think the conclusions are a very fair reading/interpretation of the current arch spec once one more thoroughly thinks about the matter.  And any critique of the spec would be that it would be desirable to have a note that explicitly clarified this matter (and not leave it as an exercise for the reader to hopefully reason intelligently enough to reach the right conclusion).

Greg

[Adnan Hamid]

Hi Greg,

Got it. Where should such questions requesting clarification of the specification from customers running live projects go ?

I asked Andrea Gallo at the CSC Face-to-face last week, and he directed me to isa-dev for now.

As an aside, in some cases Breker is simply providing an anonymizing function for the customer for theses customers who don't want to be seen asking the questions in public.

-adnan