Our IOMMU design is available now: https://drive.google.com/file/d/1sBhb_Nb93ncd4kvnDnlieISbvL4APzzW/view The overall design is very similar to Rivos's proposal. However, there are differences. Our

> 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. That explains

The Committees (who can delegate to SIGs) now constitute the mechanism for continuity as Task groups must have small tasks and end when they complete their tasks. The goal is that some committee or

P.S. It doesn't matter how good or not so good this and/or other IOMMU proposals are - that's orthogonal to the planning work that the TSC wants to see before approving a TG.

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

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

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

That makes sense; there should already be a SIG - or an HC - whose charter fits this. The memory safety SIG is certainly one choice, SOC infrastructure might be another, possibly better, choice (or

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

Adding in Mark to agree or disagree with the words I put in his mouth below. 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

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,

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

Ved wrote: Thank you, much better. (I think you could go ahead and reveal the unnamed "Member". It won't be a secret to the TG, and you may as well take some credit for your effort, in my opinion.

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

I agree. We are a community and the best solutions are jointly developed with community buy-in. A similar thing occurred with graphics and shading. We had them step and back and develop a strategy

Nick Kossifidis wrote: 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

This is definitely really promising! My group is indeed very interested. Please count on us moving forward. Thanks Sandro

Agreed and many thanks to rivos. I think Philipp and Greg as chairs of SW and Priv are discussing the best way/place to create this SIG. remember that we are matrixed and at least these two committees

CC to priv-arch: It's nice to see an IOMMU design from the community. In fact, here in T-Head we have also developed an IOMMU spec draft and it's thought-provoking to see similar designs with