Preferred Boot Coordination Method (due 11AM CST June 13, 2023)

[ballle98]

Option 1: In-band PCIe, UEFI access to the xPU over PCIe.

• New PCIe Class Codes.
• New PF0 status registers.
• Optional PF0 OS_BOOT_SELECT
• Note: DOE organizational GUID could be used instead of new registers approved by PCI-SIG)

Option 2: Platform xPU UEFI Driver Ready Check

• This would occur after PCIe enumeration. No additional devices can be added without hotplug support
• xPU must still meet PCIe timing requirements
• Platform UEFI BIOS allows xPU driver to hold boot
• Optionally this could be done with edia Presence so other UEFI drivers can load

Option 3: Out-band via platform BMC

• Platform BMC communicates OOB with xPU and hold platform in a pre-boot state before PCIe enumeration until xPU is ready
• MTCP PLDM State sensors proposed for Plat BMC to xPU coordination but not final.
• Platform BMC to BIOS communication is not defined. Local Redfish is an option but this would not be available in UEFI until after PCIe enumeration. If xPU has independent power then could be done with BMC power control.

see https://github.com/opiproject/opi-prov-life/blob/main/boot/COORDINATION.md

[glimchb]

I'm not voting, so just few comments:

• option 1
  • looks really good long term option
  • it will take a bit time to adopt/develop
  • we need to develop it some more with DOE to avoid PCI-SIG
  • I think it doesn't solve crash use cases. only initial boot...
• option 2 doesn't seem to solve any problems
• option 3 makes sense
  • but limited to only deployments with platform BMC
  • we need to define a lot more here...
    • we need to agree on PLDM, for example
    • and define registers and how to use them
    • state direction with USB...
    • more

[ballle98]

Problem I see with option option 2 is that it must happen after PCIe enumeration. Could cause issues with implementation that would make emulated devices seperate PCIe functions and don't want to support hot plug.

[samerhaj]

Selecting one option is a bit problematic, for the reasons we discussed in the meeting and on Githun (as well as what @glimchb points above).

I think options 1 and 3 have their merits and advantages. And I think they can co-exist (one is BMC/OoB focused, and one is PCIe/UEFI focused). So If I have to vote, I will vote for both 1 and 3.

Option 2 does not look like a complete solution, and does not really have advantages in my view over (1) and (3) in terms of solving the problem.

[glimchb]

and we need a plan for option1, if we go with that longer term... PCI-SIG or DOE...

[samerhaj]

Note that I voted for Option (3) in order to build consensus. But I would like for Option (1) to be considered as a long term solution as well. (The poll only allows one option for voting)

[sburla-marvell]

Option 1 will be a more comprehensive solution, it will take care of Boot time coordination, conventional reset(hot/warm/cold), FLR, hotplug etc. But option 1 needs that all the BIOS/UEFI and OSes do comply which might take a really long time, there is no uniform handling in the ecosystem for something like CRS (which is already specified in PCI spec). option 1 should be a long term goal.
Option 2 is just a PCie controller specific protocol not controller independent.
Option 3 needs to be developed more but is only applicable when BMC is in control of booting.

[samerhaj]

Does this mean your vote is for both Options 1 (long term) and 3 (OOB)? Or for all three options?