Re: [PATCH] Add direct memory access synchronize extension

Anup Patel

Hi Paul,


Everyone over here is well aware of the importance of fast-tracking basic CMO instructions and getting it frozen soon. The CMO group is also aware of their priorities so we should let them tackle this instead of proposing how they should work.


As mentioned quite a few time in this email thread, the SBI DMA sync is only a stop-gap solution (or backup plan) to tackle Linux RISC-V patch acceptance policy if we don’t get basic CMO instructions soon. We would certainly like to avoid SBI DMA sync extension if possible. In fact, we have not included SBI DMA sync extension in the recently frozen SBI v0.3-rc1 spec which will be released next month.


It is certainly possible to have basic CMO instructions frozen by 2021 year end. If this happens then we will discard SBI DMA sync proposal and emulate basic CMO instructions in OpenSBI for BeagleV and Allwinner D1 boards. In fact, Atish is still figuring out ways to avoid both SBI DMA sync and CMO instructions for at least BeagleV if that is possible.





From: Paul Walmsley <paul.walmsley@...>
Sent: 16 June 2021 05:29
To: David Kruckemyer <dkruckemyer@...>; Nick Kossifidis <mick@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; tech-unixplatformspec@...; Palmer Dabbelt <palmerdabbelt@...>; Palmer Dabbelt <palmer@...>; tech-cmo@...; John Ingalls <john.ingalls@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH] Add direct memory access synchronize extension


It would be ideal if the CMO group could focus on fast-tracking the Cache Block Maintenance Operations for Phase 1 and get opcodes assigned, and this part of the specification frozen.  The maintenance operations are mandatory for non-CPU-cache-coherent peripheral DMA to work correctly; that's why these should be completed first.   As far as I can tell, prefetch and zeroing are strictly optimizations, so it would be best if these could be delayed to a Phase 2 -- which could be developed in parallel while Phase 1 goes through the opcode committee, etc. 


Then the SBI sync extension should be superfluous. It would be ideal if we could avoid having multiple mechanisms for the same operations.


For this to work, though, the CMO group needs to move on the block maintenance instructions quickly. 



- Paul



On 6/15/21 4:33 PM, David Kruckemyer wrote:

Hi all,


My apologies as I just got wind of this discussion (I was unable to attend the last few CMO TG meetings due to travel). I think we should sync up on the CMO TG and SBI/platform efforts since there seems to be a bit of disconnect.


Regarding the CMO TG goals, we have intended to get a basic subset of operations into the profile/platform specifications for this year. The "phase 1" status is listed here:



Though honestly, a bit of this is out of date already, so expect some clarification in the coming days (just need to do some terminology cleanup).


Please do not hesitate to reach out to me with any questions (or to post questions to the the CMO TG mailing list: tech-cmo@... )






On Mon, Jun 7, 2021 at 2:35 AM Nick Kossifidis <mick@...> wrote:

Στις 2021-06-07 07:03, Anup Patel έγραψε:
> Let's have a simple SBI DMA sync extension in SBI v0.4 spec.
> The shared code pages between M-mode and S-mode will have it's own
> Challenges and we will have to define more stuff in SBI spec to support
> this (see above).

Totally agree with you, I just thought it'd be a good opportunity to
bring this up so that we can discuss it at some point, let's have
something that works and we can optimize it later on.

> It seems CMO extension might freeze sooner than we think (others can
> comment on this). If CMO extension is frozen by year end then we can
> trap-n-emulate CMO instructions instead of SBI DMA sync extension. If
> it does not freeze by year end then we will have to go ahead with
> SBI DMA sync extension as stop-gap solution.

The CMOs TG has a meeting today, I'll try and join and ask for updates
on this.

Join to automatically receive all group messages.