Design proposal for vPRO/AMT/ISM activation #298
Conversation
pierventre
requested review from
Andrea-Campanella,
se-chris-thach,
mdbalvin,
rad-szulim,
charlesmcchan,
yi-tseng-intel,
ashridatta,
teone,
callumnobleintel,
daniele-moro,
SeanCondon,
cgoea,
emmakenny,
PalashGoelIntel,
palade,
pperycz,
ltalarcz,
jakubsikorski,
sys-orch-approve,
ahalimx86,
johnoloughlin and
garyloug
as code owners
design-proposals/vpro-device.md
Outdated
| 1. AMT Supported Device | ||
| 2. ISM Supported Device | ||
| 3. No OOB Supported | ||
|
|
There was a problem hiding this comment.
I'm not sure if we will be able to distinguish between those technologies from output of rpc-go binary. I tested rpc-go on NUC that doesn't supports AMT, but supports ISM and binary was failing with error.
There was a problem hiding this comment.
AMTInfo is our only way to learn, if the deps are there and there is an error, we assume it is not supported.
design-proposals/vpro-device.md
Outdated
| inv ->> dm: Notify | ||
| activate dm | ||
| ps ->> ps: Reconcile the device | ||
| alt AMT CurrentaState provisioned |
There was a problem hiding this comment.
The provisioning will not start until RM has activated the device into MPS (POST)
| en ->> ps: Done | ||
| deactivate en | ||
| else | ||
| ps ->> ps: Retry |
There was a problem hiding this comment.
Should we try to unprovision it and then retry?
There was a problem hiding this comment.
this is a reconciliation that is requeud until DM RM creates the resource in DMT stack
| Tink-EMT image - replacement of HookOS), as this is required to activate AMT. This also requires the `heci` driver to | ||
| be included in the kernel as the `rpc-go` utility communicates with CSME over PCIe/HECI in to activate the device. | ||
|
|
||
| `Local Manageability Service` (LMS) must to be included as it is still required to enable the communication between RPC |
There was a problem hiding this comment.
this is installed as one of our agents ?
There was a problem hiding this comment.
No this a dep needed by RPC (a mix of user space, kernel modules, etc)
| Remote Provisioning Client (RPC) is launched during the provisioning flow (uOS stage). | ||
|
|
||
| vPRO (AMT & ISM) capable Core devices need to have the `rpc-go` utility embedded in the uOS image (the so called | ||
| Tink-EMT image - replacement of HookOS), as this is required to activate AMT. This also requires the `heci` driver to |
There was a problem hiding this comment.
Even though we are using tink-EMT we will be enabling vPRO on both Ubuntu and EMT, correct ?
There was a problem hiding this comment.
yes but we will not control the activation, reconfiguration in the final OS. This will come later (in 3.2) with the help of the Platform Manageability Agent
|
|
||
| Let us now analyze the device activation, the user must do the following steps before starting AMT activation | ||
|
|
||
| - AMT is enabled in BIOS |
There was a problem hiding this comment.
what is the default for this ? enabled or disabled ? (say when the device come fresh from factory ?)
There was a problem hiding this comment.
like SB and FDE we dont know - it is really dependent on the vendor. This will be part of our docs
| - **Late Binding** where RPC is integrated in the image of the final OS. If this on one side, addresses the need to | ||
| support remote deactivation and day2 reconfiguration, it does not provide a solution to recover the device if something | ||
| goes wrong during the provisioning flow and require the integration with a **Platform Manageability Agent**. | ||
| - **Cloud-Init** provisioning where AMT is activated at the end of the provisioning flow. This solution does not offer |
There was a problem hiding this comment.
why would you want this in a future release with all the disadvantages ?
There was a problem hiding this comment.
Keeping this as alternative. What we will do in 3.2 is the PMA integration
ajaythakurintel
added
the
Proposal
Checklist: