Fixing document to reflect the current state

SetupDataPkg/Docs/Overview/Overview.md

@@ -117,6 +117,9 @@ file, binary, or SVD.
 [Profiles doc](../Profiles/Overview.md).
 - The variable list binary, saved in .vl format, can be applied to a running system via dmpstore in the EFI shell,
 or via [WriteConfVarListToUefiVars.py](../../Tools/WriteConfVarListToUefiVars.py).
+- Vice versa, variables applied to target system can be fetch through ConfApp's dump configuration option in UEFI, saved
+to a file system in the EFI shell via dmpstore, or by [ReadUefiVarsToConfVarList.py](../../Tools/ReadUefiVarsToConfVarList.py)
+in the OS.
 - The SVD can be applied to a running system via USB/serial via mu_feature_config's Conf App.
 - Changes to the XML itself will result in a change to the default configuration options of a platform.
 

SetupDataPkg/Docs/PlatformIntegration/PlatformIntegrationSteps.md

@@ -66,9 +66,8 @@ configure the hardware accordingly.
 
 ## Platform Data Flow
 
-The default silicon policy should be initialized by silicon modules during early PEI after Policy Service is available.
-An example is provided in
-[mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/PolicyDataGfx/PolicyDataGfx.c).
+The default silicon policy can be initialized by silicon modules during early PEI after Policy Service is available, and
+then updated by a phase-2 module to apply the changes from configuration data to silicon policy.
 
 The OemConfigPolicyCreator should take the autogenerated data provided by PlatformConfigDataLib (via the `gKnobData`
 extern structure) and publish the config policy. This module can perform any filtering required by the OEM/platform,
@@ -82,6 +81,13 @@ Following these two operations, the n number of Config Policy to Silicon Policy
 policy and override the relevant silicon policies. An example is provided in
 [mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/ConfigKnobs/ConfigKnobs.c).
 
+Note that, for demonstration simplicity and data overhead reduction, the provided example above directly intialized the
+silicon policy and update the value using data from configuration autogen headers. In real world, this same model could
+also be considered as long as this model would not cause dependency intervention. More often though, existing silicon modules
+from major silicon vendors might already have their data pipelines, such as setup variables, structured PCDs. In those cases,
+platforms can consider updating the data that resides in the existing pipelines instead of introducing major silicon module
+overhaul.
+
 During the rest of boot process, the silicon drivers will consume the updated silicon policies to configure hardware
 components or adjust firmware configuration. An example is provided in
 [mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/QemuVideoDxe/Driver.c).