Xen project Mailing List

# Hyperlaunch: Design Session
## Xen Summit 2023

<center>Moderators: Christopher Clark, Daniel P. Smith</center>

---

# Hyperlaunch: Review of Goals

**Project goals:**
 

* HAT: Isolating Safety Critical VMs from non-Critical VMs
* Fast system start
* Static partitioning
* Dynamic partitioning via policy and configuration
* System architecture for boot domain
* A strategic advantage for the Xen hypervisor
 

**Development goal:** Merging incremental work

---
# Design Considerations

* Architecture-neutral:
* Hello Arm dom0less! and RISC-V and PPC and ...
* Common representions of boot materials
* Common domain contruction code
* Abiility for arch-specific extensions to representation and construction
 
* Upstream maintained

---

# Upcoming: Summary View

**AMD** is now a sponsor in Hyperlaunch, enabling continued development by Daniel and
Christopher to advance the work into Xen. 

Development is active:

* Series v1 being split and prepared for v2 upstream
* Rebase of whole series to 4.17.1
* Preliminary work to add PVH domain construction with mulitple domain unpause

---

# Patch Series Status:

* v1 series: July 2022

* Review feedback helpful, thanks!
* eg. approach: add fields, structure when use is introduced
* no major changes in design since posting v1

* **v2 series: imminent**, being prepared to post
* Plan agreed with the Xen Community on the Community Calls:
* **Smaller patches, a subset of v1 series functionality**
* Enables incremental merge, reduces review effort
* v2 goal: refactor Xen start logic away from multiboot

---

# Patch Series Status (cont'd):

* Forward port v1 series to 4.17 is undergoing test in parallel
* ensures full multi-VM launch functionality still working
* supports testing launch with PVH Dom0 or HWDom and 1 PVH guest

---

# v1 Series: x86-specific

* Kconfig for max number of boot modules across all of Xen
* Add all new boot structures, flag definitions, etc
* Change all boot logic after __start_xen:
* both PV and PVH dom0 construction, XSM, microcode loading
* Change all entry points prior to __start_xen:
* multiboot, PVH boot, EFI
* Change command line processing to new structures
* Move general flattened device tree code from Arm into common
* Update docs

---
# v1 Series (cont'd):

* Add a new Kconfig item for a Domain Builder using FDT
* New structure to introduce a Domain Builder, not yet used
* Implementation of a domain builder, parsing device tree to construct domains
* Conversion of dom0 creation and construction to use of the new domain builder
* Generalize dom0 logic:
* Domain creation, physmap, VCPU init; page alloc; multi PV domain
* Populate hypfs to support boot domain and runtime system use cases
* Add a tool for assisting PV domains with xenstore entries

---

# v2 Series: Still x86-specific!

**Shorter v2 series:** subset of v1 work, addressing prior feedback,
for simpler review for initial upstream merging.
 
Port of full v1 series available separately for testing of
the full feature behaviour.

---

# v2 Series Outline (in progress):

* Introduce hyperlaunch structures: convert module count
* Introduce per-arch headers and data structures: convert headroom
* Enable bootstrap mapping with hyperlaunch structures
* Port PV and PVH dom0 construction from multiboot to hyperlaunch
* Switch XSM init to hyperlaunch structures from multiboot
* Switch microcode module loading to hyperlaunch structures
* Convert PVH boot entry point from multiboot
* ...

---

# Credit and Thanks

* AMD for sponsoring our current development
* Star Lab (now WindRiver) for prior sponsorship of Hyperlaunch development
* D. DeGraaf's development of late hardware domain and early domain builder work

---

# At Summit: Discussion: #1

* There is a challenge with console I/O access as domU require Xenstore for establishing connections
 

"DomUs can use console_io hypercall when Xen is in debug. Daniel is working an approach that allows specifying whether domU console_io hypercall messages are allowed to be printed to Xen's console."

---

# At Summit: Discussion: #2

* An ultimate goal for Safety Certified will be the ability to construct domains and have a PCI device assigned at boot
 

"This is complicated situation and for these, the DomB concept was created. It will allow for Linux, a Realtime OS, or a bare metal app to be ran before the completion of Xen startup to handle complicated interfaces in a lower privilege execution environment."

---

# At Summit: Chat questions: #1

Q: When will Hyperlaunch be able to run a toolstack VM?
 *(by stacktrust)*
 

"It should be doable when the full feature is merged, ie all functionality that is in the v1 series, plus the XSM roles series. v2 series will be a subset of v1 series posted, so more work will be needed to upstream the rest. Then there will be some debugging when control domain is separate from hardware domain with testing toolstack functionality to see what assumptions of dom0 structure are there."

---

# At Summit: Chat questions: #2

Can a guest determine whether a system was started with Hyperlaunch?
 *(by stacktrust)*
 

"maybe. we could surface data in ACPI tables in PVH guests, for example.
It's a complicated one to answer; will consider for the design doc."

---

# At Summit: Chat questions: #3

What is the expected timeline for v2 series to be merged?
 *(by stacktrust)*
 

"v2 series posting: not far out; v2 series merging: will depend on review feedback"

---

# At Summit: Chat questions: #4

Q: How much work is expected for v3 series (where v3 = v1 subset that was not part of v2)? Approx timeline?
 *(by stacktrust)*
 

"v1 series was 18 patches; v2 series will be approx 6-8 patches derived from 3 of the v1 series patches, to prepare them for full on-list review.

The remaining work (15 of the v1 patches to be revisited) is appreciable, in addition to any necessary iteration on feedback on the v2 series.

..."

---

# At Summit: Chat questions: #4

*response continued:*

"This is why we're also forward-porting the full 18 patch series to Xen 4.17.1, so the full feature is testable and we're tracking updates to the upstream code that it changes."

---

# Additional References

* Primary reference: [Hyperlaunch on the Xen Project Wiki](https://wiki.xenproject.org/wiki/Hyperlaunch)
 

* [Xen Summit 2020: Reliable Platform Security Xen And The Fidelis Platform For Hardened Access Terminals - HAT](https://xen2020.sched.com/event/baXt)
 

* [Xen Summit 2021: Protection Hypervisor: Atto-sized Hypervisor Design](https://events.linuxfoundation.org/archive/2021/xen-summit/program/schedule/)

Xen Summit 2023 Design Session slides + notes: Hyperlaunch