search

riscv / riscv-aia

https://jira.riscv.org/browse/RVG-59
Creative Commons Attribution 4.0 International
81 stars 19 forks source link

Duo-PLIC of limited use? #1

Open jrtc27 opened 3 years ago

jrtc27 commented 3 years ago

Since compatibility mode is a property of the root domain only, either the entire system is using a legacy PLIC or the entire system is using a series of APLIC domains. This creates a nasty interaction between M-mode firmware and an S-mode OS where they both have to agree on which scheme is being used; firmware can't enable APLIC use because it might break an OS written to the old de-facto platform standard that used a SiFive PLIC (and since OS backwards compatibility is a far greater concern than firmware, given new SoCs need new firmware anyway, saying that's ok to do then would render CM pretty much pointless), and an OS can't enable APLIC use because it might break firmware written to the old de-facto platform standard, and maybe even new firmware that can support an APLIC if there's no nice way to inform M-mode that the PLIC's configuration has been changed underneath it and it needs to switch immediately to the APLIC driver.

How is this intended to work in practice? I struggle to see how there can be a sensible transition period. It seems to me that this would be solved if it were per-domain such that the S-mode domain can be left in compatibility mode with the OS free to change that, but the M-mode domain can be eagerly switched to APLIC mode without fear of breaking S-mode.

jrtc27 commented 2 years ago

Ping now the spec is in public review?

jhauser-us commented 1 year ago

The Duo-PLIC chapter was created at the request of members of the AIA Task Group. As the current document's preface says, at this time there are no known instances of a Duo-PLIC, even in simulation, and so long as that remains true the Duo-PLIC chapter will not be ratified.

Whether the Duo-PLIC chapter is ever ratified will depend on interest. If you are correct and none ever materializes, then I'm sure the chapter will eventually get deleted. In the meantime, there is no harm in keeping it in the document, clearly labeled as an unratified draft.

jhauser-us commented 1 year ago

This creates a nasty interaction between M-mode firmware and an S-mode OS where they both have to agree on which scheme is being used ....

How is this intended to work in practice?

Firmware is informed (by something like a PC's BIOS setting) which to enable. The loaded OS must be able to work with whichever it gets, or the configured setting is "wrong".

The choice can't be made per-domain because the original PLIC doesn't support separate control regions for multiple domains.

jrtc27 commented 1 year ago

This creates a nasty interaction between M-mode firmware and an S-mode OS where they both have to agree on which scheme is being used .... How is this intended to work in practice?

Firmware is informed (by something like a PC's BIOS setting) which to enable. The loaded OS must be able to work with whichever it gets, or the configured setting is "wrong".

The choice can't be made per-domain because the original PLIC doesn't support separate control regions for multiple domains.

Sure it can, the PLIC spec doesn't say you need to have M-mode contexts available to the S-mode OS. The OS already has to filter out which contexts to ignore, so if there aren't any for it to ignore then that's trivially achieved.

jhauser-us commented 1 year ago

For a PLIC, the priorities of all interrupts are configured in the first 4 kB of the PLIC control region. The second 4 kB has the pending bits for all interrupts. The third 4 kB has the enable bits for all interrupts for the first 32 contexts, and repeated for groups of 32 contexts.

Given this interface, there's no way to isolate the accessibility of control over subsets of interrupts for different privilege levels. So if S level has access to set the priorities of any interrupts, it has the ability to do so for all interrupts. If S level has access to change the pending bits of any interrupts, it has this ability for all interrupts. Similarly for all interrupt-enable bits. in groups of 32 contexts.

This doesn't cleanly map to the APLIC's separation of access for different interrupt domains, which is the whole point of the interrupt domains. That's why I say you can't separately configure different domains to choose either the PLIC or APLIC interface.

Now, if your point is that the PLIC interface could be expanded to separate this control for different domains, I'm sure that's true. But I have no interest in defining a new PLIC with APLIC-like features that isn't just the APLIC itself.

But if you think that would be a useful thing, and you're a member of RV International, by all means, post a message to the AIA TG mailing list asking if there's interest in upgrading the Duo-PLIC with this feature. If there is, you can propose a spec for it and promote it through the process. Be my guest.