...
Bla bla boot Protocol between HV and Guest
This provides information to OSes - e.g. where do I find my device tree information. Abstracting certain HW specifics. Base services like: real-time clock, wake-up reason,
Always been project specific outside PC world. EBBR says you do this by using UEFI APIs. The small subset of UEFI APIs that is sufficient are not too hard to handle. This is what EBBR requires.
Requirement:
- For booting guest VMs EBBR
- As EBBR allows either ACPI or Device Tree implementation, this can be chosen according to what fits best for the chosen hardware architecture.
Legacy systems like AUTOSAR?
Are hardware descriptions hardcoded in boot code in the AUTOSAR (classic) implementation, or are they typically described in some kind of model (that could be compared to device tree information).
Some systems might implement EBBR protocol and be supported by the above requirements. For systems that do not (e.g. some ported legacy AUTOSAR Classic based systems), AUTOSAR (classic) assumes compile-time definition of the hardware platform. It is therefore expected that some of the code needs to be adjusted when porting legacy AUTOSAR implementations.
OS independent
Require EBBR requirements
...