+Mark

This is really awesome !!!

The proposed IOMMU specification is quite feature rich and at-par with IOMMUs found on other major architectures.

This will certainly be a big addition to the collection of specifications owned by RISC-V International.

I would suggest to have a dedicated IOMMU SIG formed for taking the proposed IOMMU specification forward.

Best Regards,
Anup

On 01/10/21, 2:45 PM, "tech-privileged@... on behalf of Nick Kossifidis" <tech-privileged@... on behalf of mick@...> wrote:

    Hello all,

    In case you missed it we have an IOMMU proposal from Rivos:
    https://docs.google.com/document/d/1ytBZ6eDk1pAeBlZjDvm6_qqJbKQ0fMYKedyx0uoAGB0/edit

    The link is now on our wiki with the rest:
    https://lists.riscv.org/g/tech-tee/wiki/Home

    Regards,
    Nick

Nick Kossifidis wrote:
> In case you missed it we have an IOMMU proposal from Rivos:
> https://docs.google.com/document/d/1ytBZ6eDk1pAeBlZjDvm6_qqJbKQ0fMYKedyx0uoAGB0/edit

Thanks for sharing this, Nick.  I support the long-term efforts
to develop a standard RISC-V I/O MMU, but I must raise one serious
complaint at this time:

The status of this document needs to be made clear up front.  To the
best of my knowledge, this is not an official working document of
RISC-V International but rather a proposal privately drafted by Rivos.
As it stands, many readers may easily be misled into believing this
is an official RISC-V draft.  The effect is to give the impression---
however unintentionally---that Rivos is claiming for itself the
authority to speak for RISC-V International.  I advise everyone to
please be very careful to avoid this mistake.

Not long ago, I was in a similar position when I wrote the original
proposal for what is currently the working draft for the RISC-V
Advanced Interrupt Architecture (AIA).  However, that document
was clear exactly who the authors were (myself, Greg Favor, David
Kruckemyer, and Andrew Waterman), and it contained this warning in bold
at the start of every chapter:

    Warning!  This draft proposal is incomplete and has not been
    officially endorsed or accepted by the RISC-V International
    Association.

An official RISC-V SIG eventually was formed to pursue the AIA, and
the question was put to this SIG whether or not to accept the proposal
by us four authors as a working draft.  Only then, after there were no
objections, was our private proposal elevated to the status of a draft
document of RISC-V International.

Regards,

    - John Hauser

On Mon, Oct 4, 2021 at 9:53 AM Vedvyas Shanbhogue <ved@...> wrote:

> A similar thing occurred with graphics and shading. We had them step and
> back and develop a strategy with an eye to what it will take for a
> member to be successful in this area including gaps and prioritization
> of filling those gaps.I suggest we do the same here. In order to get TSC
> to approve a new TG, we will need to present them the whole picture and
> how this fits into it. We will require the same for IOMMU.

Thank you Mark. We started the discussion at Nick's memory safety SIG to
present the proposal to start the collaboration with goal of working out
the whole picture for the IOMMU and bring a recommendation to the TSC.
Please let us know if the memory safety SIG is the right place to
continue this discussion.

What Mark is saying is that an "IOMMU" SIG needs to be created.  Once the strategy big picture is worked out by the SIG (which provides context to the TSC for creation of any resulting TGs), it can then foster the creation of an IOMMU TG under the SoC Infrastructure HC.  Ideally this SIG would also be under the SoC Infrastructure HC, but to avoid waiting for that HC to be spun up, a similar thing can be done as was done for AIA.  Note that the Priv spec, the H extension, AIA, and the IOMMU architectures all need to be fully consistent and compatible architecturally.  And similar software PoC work will be needed as was done for Priv 1.12 + H + AIA, i.e. putting in support into Linux, KVM, and Xvisor.

Any memory safety SIG presumably has scope across all RISC-V architecture and should be concerned about safety issues wrt Priv 1.12, H, the new virt-mem extensions, the pointer masking extension, AIA, CLIC, IOMMU, RAS, and the list goes on.  All these things have dotted line involvement into this and other security-related SIGs (i.e. the scope of "memory safety" is narrower than things like AIA and IOMMU and other system components).

I believe Philipp is starting to work through the initial process to create an IOMMU SIG, which will lead to having chair/vice-chair elections, creating and approving a charter, etc. so that the SIG can start working on the strategy big picture to then set the stage for TSC approving creation of an IOMMU TG.  (Tbd whether the SIG continues to exist with focus on the overall "I/O access control/protection" topic that "IOMMU" is a big part of, or effectively it "converts" into a focused TG if there isn't any more to the big picture than needing a first gen enterprise-class IOMMU.)

Greg

Actually I believe Mark was saying that first a SIG is needed to formulate overall strategy and gap analysis, and establish the context for the TSC to  approve a focused TG (which, for example, may focus on a set of first gen needs and defer to a phase 2 TG to develop second gen enhancements - versus taking longer to develop everything in one fell swoop).

The following are the statements by Mark that I'm referring to.

Greg

Mark wrote:

> A similar thing occurred with graphics and shading. We had them step and
> back and develop a strategy with an eye to what it will take for a
> member to be successful in this area including gaps and prioritization
> of filling those gaps.I suggest we do the same here. In order to get TSC
> to approve a new TG, we will need to present them the whole picture and
> how this fits into it. We will require the same for IOMMU.

I don't see any need to create a SIG in this instance; this is a specification for a component required in SoCs - such extensions are widely in use by other ISAs. Furthermore, as Mark pointed out, others have already created their own proprietary solutions. It is time for RISC-V to come together and define a standard architecture for an IOMMU.

As Mark said, the next step is to create a TC. The responsibility for this lies in the Privileged IC.

Thanks,

Ken

On Mon, Oct 4, 2021 at 2:50 PM Greg Favor <gfavor@...> wrote:

On Mon, Oct 4, 2021 at 9:53 AM Vedvyas Shanbhogue <ved@...> wrote:

> A similar thing occurred with graphics and shading. We had them step and
> back and develop a strategy with an eye to what it will take for a
> member to be successful in this area including gaps and prioritization
> of filling those gaps.I suggest we do the same here. In order to get TSC
> to approve a new TG, we will need to present them the whole picture and
> how this fits into it. We will require the same for IOMMU.

Thank you Mark. We started the discussion at Nick's memory safety SIG to
present the proposal to start the collaboration with goal of working out
the whole picture for the IOMMU and bring a recommendation to the TSC.
Please let us know if the memory safety SIG is the right place to
continue this discussion.

What Mark is saying is that an "IOMMU" SIG needs to be created.  Once the strategy big picture is worked out by the SIG (which provides context to the TSC for creation of any resulting TGs), it can then foster the creation of an IOMMU TG under the SoC Infrastructure HC.  Ideally this SIG would also be under the SoC Infrastructure HC, but to avoid waiting for that HC to be spun up, a similar thing can be done as was done for AIA.  Note that the Priv spec, the H extension, AIA, and the IOMMU architectures all need to be fully consistent and compatible architecturally.  And similar software PoC work will be needed as was done for Priv 1.12 + H + AIA, i.e. putting in support into Linux, KVM, and Xvisor.

Any memory safety SIG presumably has scope across all RISC-V architecture and should be concerned about safety issues wrt Priv 1.12, H, the new virt-mem extensions, the pointer masking extension, AIA, CLIC, IOMMU, RAS, and the list goes on.  All these things have dotted line involvement into this and other security-related SIGs (i.e. the scope of "memory safety" is narrower than things like AIA and IOMMU and other system components).

I believe Philipp is starting to work through the initial process to create an IOMMU SIG, which will lead to having chair/vice-chair elections, creating and approving a charter, etc. so that the SIG can start working on the strategy big picture to then set the stage for TSC approving creation of an IOMMU TG.  (Tbd whether the SIG continues to exist with focus on the overall "I/O access control/protection" topic that "IOMMU" is a big part of, or effectively it "converts" into a focused TG if there isn't any more to the big picture than needing a first gen enterprise-class IOMMU.)

Greg

On Mon, Oct 4, 2021 at 5:54 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:

Mark wrote:

> A similar thing occurred with graphics and shading. We had them step and
> back and develop a strategy with an eye to what it will take for a
> member to be successful in this area including gaps and prioritization
> of filling those gaps.I suggest we do the same here. In order to get TSC
> to approve a new TG, we will need to present them the whole picture and
> how this fits into it. We will require the same for IOMMU.

This is also what happened with the aborted RAS group, i.e. it started off wanting to focus on just one thing without first establishing overall RAS strategy, gaps, and plan of attack.

Greg

RISC-V policy does not require a SIG. Clearly this IOMMU proposal is well thought out. But it is just a starting point; the whole community is welcome to contribute to the IOMMU TG. You are free to bring up any issues you want in the IOMMU TG.

On Mon, Oct 4, 2021 at 8:16 PM Greg Favor <gfavor@...> wrote:

On Mon, Oct 4, 2021 at 5:54 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:

Mark wrote:

> A similar thing occurred with graphics and shading. We had them step and
> back and develop a strategy with an eye to what it will take for a
> member to be successful in this area including gaps and prioritization
> of filling those gaps.I suggest we do the same here. In order to get TSC
> to approve a new TG, we will need to present them the whole picture and
> how this fits into it. We will require the same for IOMMU.

This is also what happened with the aborted RAS group, i.e. it started off wanting to focus on just one thing without first establishing overall RAS strategy, gaps, and plan of attack.

Greg

On Mon, Oct 4, 2021 at 6:31 PM Allen Baum <allen.baum@...> wrote:

But getting it started quickly is more important than figuring out exactly which pigeonhole to put it in, especially given the interest that has been expressed.

Hence why doing sort of like what was done for AIA is the tack being taken (i.e. creating a SIG under the existing Software HC - especially since there are big software support and software PoC tasks to happen).  Then that SIG can do its thing and can quickly get to enabling the TSC to approve creation of a TG under the SoC Infrastructure HC.

Greg

I think this is where RVI and Mark will differ.  Even though not everything must go through a SIG, the TSC (going forward) expects roadmap/strategy/gap work in place first before one or more specific tightly-focused TGs are spun up.

Greg

On Mon, Oct 4, 2021 at 6:36 PM Ken Dockser <kad@...> wrote:

RISC-V policy does not require a SIG. Clearly this IOMMU proposal is well thought out. But it is just a starting point; the whole community is welcome to contribute to the IOMMU TG. You are free to bring up any issues you want in the IOMMU TG.

On Mon, Oct 4, 2021 at 8:16 PM Greg Favor <gfavor@...> wrote:

On Mon, Oct 4, 2021 at 5:54 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:

Mark wrote:

> A similar thing occurred with graphics and shading. We had them step and
> back and develop a strategy with an eye to what it will take for a
> member to be successful in this area including gaps and prioritization
> of filling those gaps.I suggest we do the same here. In order to get TSC
> to approve a new TG, we will need to present them the whole picture and
> how this fits into it. We will require the same for IOMMU.

This is also what happened with the aborted RAS group, i.e. it started off wanting to focus on just one thing without first establishing overall RAS strategy, gaps, and plan of attack.

Greg