|
We have a new revision of our IOMMU spec. The Latex source is available on github for readers to find out the changes more easily moving forward.
https://github.com/sqzsq/xuantie-iommu-spec
Also you can find a compiled PDF in the folder. Feel free to post any comments.
Regards,
Siqi
|
|
|
Mark Hi -
Could I take you up on the offer to get
on a phone? The thread has gone cold and at least I am unclear as
to how to move forward.
I understand that we want to form a SIG
to flesh out the items you listed but need your help and guidance
on how to get that off the ground.
regards
ved
On 10/4/21 9:20 PM, Mark Himelstein
wrote:
toggle quoted message
Show quoted text
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 SIG tells us the big picture so we know
all the pieces that must be there for members to be successful
and govern across a number of task groups who may do
individual components of the overall effort.
Rather than
continue with dozens of emails, it might be useful to get on
the phone to quickly resolve any of your questions. I can do
that. Let me know.
Mark
On Mon, Oct 4, 2021 at 6:48 PM
Greg Favor < gfavor@...>
wrote:
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:
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
|
|
|
Our IOMMU design is available now: https://drive.google.com/file/d/1sBhb_Nb93ncd4kvnDnlieISbvL4APzzW/viewThe overall design is very similar to Rivos's proposal. However, there are differences. Our design considers smaller-scale systems thus the overall interface is kept simple. It also features a more aggressive idea for efficient virtualization support. Comments are welcome. Regards, Siqi
|
|
|
> 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 why the mailing list has been quiet since June! It might be an idea to post some kind of a status update to tech-rasd to inform folks who weren't party to the discussion/decision to abort.
|
|
|
mark
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 SIG tells us the big picture so we know all the pieces that must be there for members to be successful and govern across a number of task groups who may do individual components of the overall effort.
Rather than continue with dozens of emails, it might be useful to get on the phone to quickly resolve any of your questions. I can do that. Let me know.
Mark
On Mon, Oct 4, 2021 at 6:48 PM Greg Favor < gfavor@...> wrote: 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: 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
|
|
|
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.
On Mon, Oct 4, 2021 at 6:43 PM Greg Favor < gfavor@...> 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: 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
|
|
|
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
|
|
|
Ken Dockser
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: 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
|
|
|
Allen Baum
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 would be if it had a chair). It clearly will have dotted lines in several different directions 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.
On Mon, Oct 4, 2021 at 4:30 PM Ken Dockser < kad@...> wrote: 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,
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
|
|
|
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
|
|
|
Adding in Mark to agree or disagree with the words I put in his mouth below.
Greg
On Mon, Oct 4, 2021, 5:47 PM Greg Favor < gfavor@...> wrote: 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.
|
|
|
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.
|
|
|
Ken Dockser
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,
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 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
|
|
|
Ved wrote: The document has been updated with the disclaimer you suggested. 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. But I'll leave that to your choice.) - John Hauser
|
|
|
On 10/4/21 9:05 AM, 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.
That being said, I am grateful that this topic is now getting attention.
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. On Fri, Oct 1, 2021 at 2:20 PM John Hauser <jh.riscv@... 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.
Thanks John for pointing out the convention. I am still new to the community and was not aware of this. The goal bringing the proposal to the memory safety SIG was to start this discussion. The document has been updated with the disclaimer you suggested. regards ved
|
|
|
mark
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 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.
That being said, I am grateful that this topic is now getting attention.
Mark
On Fri, Oct 1, 2021 at 2:20 PM John Hauser < jh.riscv@...> wrote: 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
|
|
|
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
|
|
|
This is definitely really promising!
My group is indeed very interested.
Please count on us moving forward.
Thanks
Sandro
|
|
|
