Break-before-make approach (BBM) during MMU page tables update

[Oleksii Kurochko]

Hello Community,

In the RISC-V specification, it is not explicitly stated whether BBM (Break-Before-Make) is mandated when updating a page table entry.

Consider the following case where a superpage is being split:

```

         ...

         if ( !split_superpage(&split_pte, level, target, offsets) )
         {
             /* Handle failure to split the superpage */
             ...
         }

------> /* Should BBM be used here? */
         write_pte(entry, split_pte);
         ...

```

Is it necessary to invalidate (i.e., clear the entry) and flush the TLB before calling write_pte()?
If not, what part of the RISC-V specification permits skipping BBM in this scenario?

For example, Arm mandates to do BBM: https://developer.arm.com/documentation/ka006181/latest/

Thanks in advance.

[Radim Krčmář]

2025-07-23T02:14:52-07:00, Oleksii Kurochko <oleksii....@gmail.com>:
> *Hello Community,*

>
> In the RISC-V specification, it is not explicitly stated whether BBM
> (Break-Before-Make) is mandated when updating a page table entry.
>
> Consider the following case where a superpage is being split:
>
> ```
>
> ...
> if ( !split_superpage(&split_pte, level, target, offsets) )
> {
> /* Handle failure to split the superpage */
> ...
> }
>
> ------> /* Should BBM be used here? */
> write_pte(entry, split_pte);
> ...
> ```
>
> Is it necessary to invalidate (i.e., clear the entry) and flush the TLB
> before calling write_pte()?

I don't think so. Software just cannot predict which translation entry
is going to be used until a sfence.vma.

(I think it's better to only flush afterwards, because the TLB might
cache invalid entries, and software shouldn't get anything from
flushing twice.)

> If not, what part of the RISC-V specification permits skipping BBM in this
> scenario?

There is somewhat relevant non-normative text in the NAPOT chapter:

If any inconsistencies do exist, then the effect is the same as when
SFENCE.VMA is used incorrectly: one of the translations will be
chosen, but the choice is unpredictable.

Hope that helps.

[Oleksii Kurochko]

On Friday, July 25, 2025 at 7:49:56 PM UTC+2 rkr...@ventanamicro.com wrote:

2025-07-23T02:14:52-07:00, Oleksii Kurochko <oleksii....@gmail.com>:
> *Hello Community,*
>
> In the RISC-V specification, it is not explicitly stated whether BBM
> (Break-Before-Make) is mandated when updating a page table entry.
>
> Consider the following case where a superpage is being split:
>
> ```
>
> ...
> if ( !split_superpage(&split_pte, level, target, offsets) )
> {
> /* Handle failure to split the superpage */
> ...
> }
>
> ------> /* Should BBM be used here? */
> write_pte(entry, split_pte);
> ...
> ```
>
> Is it necessary to invalidate (i.e., clear the entry) and flush the TLB
> before calling write_pte()?

I don't think so. Software just cannot predict which translation entry
is going to be used until a sfence.vma.

I think you are right. I also found the following what IMO proves that what

you said is correct:

```

It is permitted for multiple address-translation cache entries to co-exist for the same
address. This represents the fact that in a conventional TLB hierarchy, it is possible for
multiple entries to match a single address if, for example, a page is upgraded to a
superpage without first clearing the original non-leaf PTE’s valid bit and executing an
SFENCE.VMA with rs1=x0, or if multiple TLBs exist in parallel at a given level of the
hierarchy. In this case, just as if an SFENCE.VMA is not executed between a write to the
memory-management tables and subsequent implicit read of the same address: it is
unpredictable whether the old non-leaf PTE or the new leaf PTE is used, but the behavior is

otherwise well defined 

```

(I think it's better to only flush afterwards, because the TLB might
cache invalid entries, and software shouldn't get anything from
flushing twice.)

> If not, what part of the RISC-V specification permits skipping BBM in this
> scenario?

There is somewhat relevant non-normative text in the NAPOT chapter:

If any inconsistencies do exist, then the effect is the same as when
SFENCE.VMA is used incorrectly: one of the translations will be
chosen, but the choice is unpredictable.

Hope that helps.

It helps a lot. Thanks.