|
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:
toggle quoted message
Show quoted text
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@... )
Cheers,
David
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.
|
|
|
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.
Regards,
Anup
toggle quoted message
Show quoted text
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:
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.
|
|
|
FWIW, our (the CMO TG's) priorities are in order as follows:
- Zicbom (maintenance) - Zicboz (zero) - Zicbop (prefetch)
We happen to have provisional opcodes for both Zicbom and Zicboz (mostly since they occupy the same real estate).
The primary goal now is to take our overly general spec and distill it down into the three extensions and limit it to the Phase 1 material. Volunteers to help out with that would be greatly appreciated.... :)
Cheers, David
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.
Regards,
Anup
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:
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.
|
|
|
Allen Baum
Arch-test should be involved also. It is (more than) a bit complicated because CMOs are instructions that affect non-architectural bits of an implementation - so it's unclear what it even means to have an architectural test, much less how to write one. The framework and tests are currently only handling deterministic archtecutral state and The definition of done has an architectural test component, and a proof of concept component. The CMOs can only do the proof-of-concept part because of the above.
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@... )
Cheers, David
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.
|
|
|
