...
Alternative to discuss: Should certain features be mandatory (to be compliant with) the virtual platform (i.e. available for use if the OEM product requires them)?
Usage of built-in virtualization in hardware
Req: If running on hardware that supports it, then the architectural virtualization interfaces (for interrupts and timers, performance monitoring, ...) shall be used where available.
?? Does this not weaken the standardization? In some cases supporting (VIRTIO) abstraction might be more standard.
Matti: No, these features do not overlap with VIRTIO typically.
2.5 Booting Guests
Placeholder
...
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 Systems that support a dynamic boot protocol should implement (the mandatory parts of*) EBBR
- As EBBR allows either ACPI or Device Tree implementation, this can be chosen according to what fits best for the chosen hardware architecture.\
*TBD: Figure out of some optional EBBR requirements should be mandatory in this specification.
Legacy systems like AUTOSAR?
- For systems that do not support a dynamic boot protocol (see discussion), the virtual hardware shall be described (by HV vendor) using a device tree format so that implementors can program custom boot and setup code
DiscussionAre 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 not realistically 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 and other RTOS guests). These are typically implemented using 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
such systems to a virtual platform.
Option 1) HV exposes the expected devices in the expected location (and behavior) of an existing legacy system.
Option 2) HV decides where to place device features and communicate that to the operating system. This would be done by device-tree snippets (statically defined)
More to do: "Standard" for how HV describes hardware/memory map to legacy system guests, and recommendations for how to port legacy systems accordingly.
Consensus seems to be: Device Tree (independent specification at https://devicetree.org) used as a human readable specification (i.e. the boot code could still be hard-coded and do not need to support a lot of runtime configuration) → see requirement above.
TBD: Linux and Android have different boot req
Android can be booted using UEFI - likely ebbr req will work for both.
3. Common Virtual Device categories
...