Merge pull request #2671 from pareenaverma/content_review

MEC section edits to CCA LP

Author: pareenaverma

content/learning-paths/servers-and-cloud-computing/cca-container/cca-mec.md

@@ -14,29 +14,28 @@ Download the [`armswdev/cca-learning-path:cca-simulation-v3`](https://hub.docker
 
 ## About Memory Encryption Context (MEC)
 
-Memory Encryption Contexts (MEC) are configurations of encryption that are associated with areas of memory, assigned by the MMU.
+Memory Encryption Contexts (MEC) is an extension of the Arm Realm Management Extension (RME). MEC extends the existing support for memory encryption, allowing multiple encryption contexts in the Realm Physical Address Space. In an RME system with MEC, each access to a physical address is tagged with a Memory Encryption Context Identifier (MECID), which associates the access with a specific memory encryption context. The Arm Confidential Compute Architecture (CCA) requires that the Realm, Secure, and Root PASes are encrypted. Without MEC, the encryption context used within each PAS is global to that PAS. For example, all Realm memory would use the same encryption context.
 
-MEC is an extension to the Arm Realm Management Extension (RME). The RME system architecture requires that the Realm, Secure, and Root PASes are encrypted. The encryption key or tweak, or encryption context, used with each of these PASes is global within that PAS. So, for example, for the Realm PAS, all Realm memory uses the same encryption context.
+With MEC, this model is extended. Non-secure, Secure, and Root PAS accesses use a default MECID value (0), while the Realm PAS supports multiple MECIDs. This allows each Realm to use a distinct memory encryption context, providing additional defense in depth beyond the isolation already provided by RME. The Realm Management Monitor (RMM) itself can also use a separate encryption context.
 
-With MEC this concept is broadened, and for the Realm PAS specifically, this allow each Realm to have a unique encryption context. This provides additional defense in depth to the isolation already provided in RME. Realms and RMM itself can all have separate encryption. MECIDs are identifying tags that are associated with different Memory Encryption Contexts. MECIDs are assigned to different software entities in the system, for example, Realms or the RMM.
 
-## RMM without FEAT_MEC
+## Run the FVP without FEAT_MEC
 
-When the FVP starts, it can be configured to advertize that it has MEC support by setting `FEAT_MEC` in the system configuration registers. The CCA software stack will detect that MEC is available, and as configured in the CCA stack built for the `armswdev/cca-learning-path:cca-simulation-v3` will make use of it.
+When the FVP starts, it can advertise support for MEC by exposing the `FEAT_MEC` CPU feature. The CCA software stack detects whether `FEAT_MEC` is available and enables MEC support accordingly.
 
-First, fire up a container:
+First, start the docker container:
 
 ```console
 docker run --rm -it armswdev/cca-learning-path:cca-simulation-v3
 ```
 
-Then start a CCA host in the FVP (without MEC):
+Then start a CCA host in the FVP without enabling MEC:
 
 ```console
 ./run-cca-fvp.sh
 ```
 
-This boots the 3 worlds. Switch to the second screen of `screen` by pressing `ctrl+a 2`, which corresponds to the output console of the RMM. It should look like:
+This boots the 3 worlds. Switch to the second `screen` console by pressing `ctrl+a 2`, which corresponds to the RMM output console. The output on the console should look similar to:
 
 ```output
 Trying ::1...
@@ -68,19 +67,19 @@ RMM_MEM_SCRUB_METHOD=2 is set but FEAT_MEC is not present.
 SMC_RMI_VERSION                   10000 > RMI_SUCCESS 10000 10001
 ```
 
-Note how the RMM has detected `FEAT_MEC`is not available --- and complains about it.
+The messages indicate that the RMM has detected that FEAT_MEC is not available.
 
 You can now bring down the FVP simulation. Switch back to the main `screen` console with `ctrl+a 1`, log in as `root` (no password) and `poweroff` to exit.
 
-## RMM with FEAT_MEC enabled
+## Run the FVP with FEAT_MEC enabled
 
-Now, start the CCA host in the FVP with `FEAT_MEC` enabled:
+Next, start the CCA host in the FVP with `FEAT_MEC` enabled:
 
 ```console
 ./run-cca-fvp.sh --enable-mec
 ```
 
-This boots the 3 worlds again. Switch to the RMM output console (second screen of `screen` with `ctrl+a 2`). It should look like:
+This again boots the three worlds. Switch to the RMM output console (ctrl+a 2). It should look similar to:
 
 ```output
 Trying ::1...
@@ -104,6 +103,8 @@ RMM_MEM_SCRUB_METHOD 2 is selected.
 SMC_RMI_VERSION                   10000 > RMI_SUCCESS 10000 10001
 ```
 
-With `FEAT_MEC` enabled, the RMM detects it and no longer complain about it missing. The RMM will now use different memory encryption contexts for each of the realms that you would start with the `lkvm` command from the previous pages.
+With FEAT_MEC enabled, the RMM detects MEC support and no longer reports it as missing. The RMM will now make use of multiple memory encryption contexts, assigning distinct MECIDs to Realms that you create using the lkvm command in the previous sections of this learning path.
 
-You can now bring down the FVP simulation. Switch back to the main `screen` console with `ctrl+a 1`, log in as `root` (no password) and `poweroff` to exit. You can also exit the docker container with `exit`.
+You can now shut down the FVP simulation. Switch back to the main screen console with ctrl+a 1, log in as root (no password), and run poweroff to exit. You can then exit the docker container with exit.
+
+You have learned how to enable Memory Encryption Contexts (MEC) on the FVP and verified that the RMM detects and uses this capability.