Add RPMI MPXY Integration chapter #49
Conversation
src/intro.adoc
Outdated
|
|
||
| [#img-transport-topologies] | ||
| .Transport for M-Mode and S-Mode | ||
| image::transport-topologies.png[width=800,height=800, align="center"] | ||
|
|
||
| RPMI is designed to work with a single or multi-tenant topology as shown | ||
| above. | ||
| ==== RPMI Instance |
There was a problem hiding this comment.
Similar to "RPMI client"?
some chapter uses "client".
There was a problem hiding this comment.
No, client is always meant as a driver or SW which sends the RPMI message or data.
RPMI client uses an RPMI instance to do that.
If somewhere client is misinterpreted then we need to correct that
There was a problem hiding this comment.
yes, i saw some use 'client' in other chapters.
src/srvgrp-base.adoc
Outdated
| @@ -197,10 +200,10 @@ the `MAJOR` and `MINOR` numbers. | |||
| ! Description | |||
|
|
|||
| ! [31:16] | |||
| ! `MAJOR` number | |||
| ! `MAJOR` Number | |||
There was a problem hiding this comment.
need capital letter for ‘N'?
src/srvgrp-base.adoc
Outdated
| ! [31:2] | ||
| ! _Reserved_ and must be `0`. | ||
| ! [31:3] | ||
| ! _Reserved, must be initialized to_ `0`. |
There was a problem hiding this comment.
the whole sentence needs to be italic xxx font?
There was a problem hiding this comment.
Thats how i have done for all groups which i have updated so far
There was a problem hiding this comment.
But now i see its not same everywhere
There was a problem hiding this comment.
I will make only RESERVED as italic so we have less work to do
There was a problem hiding this comment.
yes, Joshua previous patch make them all to "Reserved and must be 0."
There was a problem hiding this comment.
Thats why i was wondering why suddenly this changed since i did the older way
I will let you and Joshua do these kind of formatting now :) Will save everyones time
src/srvgrp-base.adoc
Outdated
| @@ -502,17 +524,17 @@ processor will take the wired interrupt. | |||
| | 0 | |||
| | MSI_ADDRESS_LOW | |||
| | uint32 | |||
| | Lower 32-bit of the MSI address. | |||
| | Lower 32-bit of the MSI address | |||
There was a problem hiding this comment.
your patch revert changes from Joshua?
There was a problem hiding this comment.
Yes, sorry, i had to merge manually while rebasing and missed couple of changes
src/srvgrp-base.adoc
Outdated
| ! _Reserved, must be initialized to_ `0`. | ||
|
|
||
| ! [2] | ||
| ! The RISC-V privilege level to which the RPMI instance belong. |
There was a problem hiding this comment.
Then Firmware needs to know this and return the correct mode?
why we need this?
There was a problem hiding this comment.
Now combining this information with the MPXY chapter requirement. The M-Mode RPMI instance will know exactly which service groups will belong to MPXY and which will not
There was a problem hiding this comment.
but this information need retrieve from platform microcontroller?
There was a problem hiding this comment.
Because based on the mailbox we will create platform microcontroller will know which mailbox is meant for M-Mode and which one for S-Mode. Thats how a transport itself establishes as Secure or non secure
There was a problem hiding this comment.
PuC and DT details for mailbox have to be in sync
There was a problem hiding this comment.
but this also means needs to be fixed, can't have one PuC FW to support different use cases. Need to update PuC FW.
There was a problem hiding this comment.
This will be fixed only, its really a static information since you will be fixing the mailbox(shared memory) and assigning it for an RPMI instance and then providing it to DT. PuC firmware already aware of this and its a static detail. This could have been a part of DT node also but you need additional or new DT properties to encode this
src/rpmi-mpxy.adoc
Outdated
| :rootpath: ./../ | ||
| endif::rootpath[] | ||
|
|
||
| == RPMI Integration with SBI MPXY extension. |
There was a problem hiding this comment.
remove full stop in header.
extension change to "Extension"
src/rpmi-mpxy.adoc
Outdated
| exposed to the S-mode over SBI MPXY interface and RPMI message protocol specific | ||
| attributes for MPXY channel. | ||
|
|
||
| The service groups that have dedicated SBI extension cannot be |
There was a problem hiding this comment.
In the previous meeting, there were people commenting about this, right? One example is CPPC, people might want to use S-mode RPMI with fast-channel?
Page 10, Recommendation for "Exclusive Interface Choice with MPXY or S-mode RPMI for a Specific RPMI Service Group"
https://docs.google.com/presentation/d/1EsrcgUZiXf_mqt4Wcd0oiRyLw4ZIGaVMa6Ew0GZ7hoQ/edit#slide=id.g2cd11e3ec8b_9_7
There was a problem hiding this comment.
I have already mentioned that this case is when RPMI instance is in M-Mode. S Mode RPMI instance can implement CPPC at their wish.
There was a problem hiding this comment.
I have already mentioned that this case is when RPMI instance is in M-Mode. S Mode RPMI instance can implement CPPC at their wish.
got this part?
src/service-groups.adoc
Outdated
|
|
||
| The following table lists the service group | ||
| In each service group the `SERVICE_ID = 0x00` is dedicated to a notification type | ||
| service used to send events notification and a `SERVICE_ID = 0x1` dedicated for |
src/srvgrp-system-reset.adoc
Outdated
| @@ -27,7 +27,8 @@ necessary to categorize it as a graceful or forceful shutdown. In the case of | |||
| a shutdown request, it is implicit for the platform microcontroller that the | |||
| application processor has prepared itself for a successful shutdown. | |||
|
|
|||
| Below table lists the services in this group: | |||
| Below table lists the services in the SYSTEM_RESET service group: | |||
There was a problem hiding this comment.
"The following table lists the services in the SYSTEM_RESET service group:"
All service groups can follow the same.
src/srvgrp-system-suspend.adoc
Outdated
| @@ -18,7 +18,8 @@ platform microcontroller that all the application processors except the one | |||
| requesting are in `STOPPED` state and necessary state saving in the RAM has | |||
| been complete. | |||
|
|
|||
| Below if the list of services in this group: | |||
| Below if the list of services in the SYSTEM_SUSPEND service group: | |||
pathakraul
force-pushed
the
rpathak_mpxychapter
branch
4 times, most recently
from
323f707
to
d13b8a5
Compare
Signed-off-by: Rahul Pathak <[email protected]>
Signed-off-by: Rahul Pathak <[email protected]>
Signed-off-by: Rahul Pathak <[email protected]>
Signed-off-by: Rahul Pathak <[email protected]>
pathakraul
force-pushed
the
rpathak_mpxychapter
branch
from
d13b8a5
to
4d1403f
Compare
Signed-off-by: Rahul Pathak <[email protected]>
|
|
||
| | 0x0001 | ||
| | | ||
| | BASE | ||
| | M-mode, S-mode |
There was a problem hiding this comment.
In the get privilege level service, it only has M-mode and Non M-mode.
Should we change S-mode here to S-Mode and U-Mode? Or no limit to any privilege level
There was a problem hiding this comment.
No, We are fixing the Base service group attribute to convey whats possible, and by Non-M-Mode we can encompass what may be possible in future.
This table is explicit about whats "currently" possible. And this table is also in constant update if anything changes in future
| image::mpxy-rpmi.png[350,350, align="center"] | ||
|
|
||
| RPMI service groups that are M-mode only, including BASE, which is an exception | ||
| must not be accessible via SBI MPXY interface. A MPXY channel |
There was a problem hiding this comment.
This mean BASE service group can't use SBI MPXY interface?
There was a problem hiding this comment.
I thought we want allow BASE via MPXY after that
There was a problem hiding this comment.
S-mode software can get some basic information of RPMI, such as RPMI version etc..
There was a problem hiding this comment.
Few things to consider -
RPMI Base was never meant for the MPXY. RPMI base group only and only manages a RPMI context. MPXY channel is not a RPMI context. Its not even a RPMI transport. But you are right that these details are required and thats why we have attributes in the MPXY channel.
From your comment i just added Service group version as an attribute also in the MPXY chapter. So, all these things like RPMI
version and service group version whatever is required by a MPXY client using RPMI, has to be via channel attributes, either Standard or Message Proto specific attributes.
Signed-off-by: Rahul Pathak <[email protected]>
Signed-off-by: Rahul Pathak <[email protected]>
No description provided.