Re: [PATCH v6 2/4] target/riscv: implement Zicboz extension

[Daniel Henrique Barboza]

On 2/18/23 16:35, Richard Henderson wrote:
> On 2/17/23 23:28, Daniel Henrique Barboza wrote:
> > "A cache-block zero instruction is permitted to access the specified cache 
> > block whenever
> > a store instruction is permitted to access the corresponding physical addresses 
> > and when
> > the PMAs indicate that cache-block zero instructions are a supported access 
> > type. If access
> > to the cache block is not permitted, a cache-block zero instruction raises a 
> > store page fault
> > or store guest-page fault exception if address translation does not permit 
> > write access or
> > raises a store access fault exception otherwise. During address translation, 
> > the instruction
> > also checks the accessed and dirty bits and may either raise an exception or 
> > set the bits as
> > required."
>
> By the way, I think the documentation should specify what happens if the page 
> is *not* accessible.  Is badaddr = {rN, aligned(rN), unspecified, but somewhere 
> in the block}?

Do you mean that the doc should tell whether the address to be returned in the 
store
access fault should be aligned and whatnot?

Yeah, this is not mentioned in the docs. I think you're wondering if we should 
do like
ARM does, like you're mentioned in the previous version:

=======
While re-reading the ARM code, I remembered that the ARM dc.zva instruction is 
required
to produce original unmasked address on a page fault, thus the little dance 
with two
calls to probe_write.
=======

By reading target/riscv code it seems that all store acess faults are being 
fired via
raise_mmu_exception(), which is only called in riscv_cpu_tlb_fill(), which in 
turn
doesn't do any thing special with the address before firing the exception. So I 
guess
we can assume that badddr = aligned?



Daniel


> r~