Re: Working Group Meeting for hyperlaunch

[Christopher Clark <christopher.w.clark@xxxxxxxxx>]

On Thu, Mar 18, 2021 at 8:33 AM Daniel P. Smith
<dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On 3/16/21 12:09 AM, Daniel P. Smith wrote:
> > All,
> >
> > We have posted[1][2] the design documents for hyperlaunch and would
> > invite attendance at a working group call to discuss two agenda items.
> > The first item is a review of the documents and the second is a
> > discussion about bringing production-ready revisions of our previous
> > prototype in as patches to provide a near-term implementation of the
> > design. If possible please join us this Thursday 3/18 at
> > 1700CET/1600GMT/1200EDT/0900PDT. Below are the call details.
> >
> > [1]
> > https://lists.xenproject.org/archives/html/xen-devel/2021-03/msg00939.html
> > [2]
> > https://lists.xenproject.org/archives/html/xen-devel/2021-03/pdfCV4LaWCrTN.pdf
>
> Agenda link,
> https://cryptpad.fr/pad/#/2/pad/edit/+MJgJ0EkalH81-YVOlsp1bEo/

## Minutes from the Hyperlaunch Working Group meeting, 18th March

* Posted design docs:
    1) main doc: has the high level design
    2) device tree doc: has implementation details for launch

- new version of docs much better, in-line with vision for Xen design docs
- Xen tree has example of another good recent design doc

- Stefano: have minor feedback on some details eg. node names
Evaluating fit with work on System Device Tree; is very aligned.

* Naming: "Hyperlaunch" and the related terms "Hyperlaunch Static"
and "Hyperlaunch Dynamic"

- No objections; proceeding with these names for now
- OK to retire term 'dom0less' in favour of 'Hyperlaunch Static' since
  Hyperlaunch Static will do everything that dom0less does, plus more
- an Appendix in the posted main design document has reasoning,
  rationale behind the proposed naming

* Towards merging:
- Andy: Xen currently in release freeze, so wait for opening for
  4.16, and then follow up

* Crash domain: When is it started? What defines a crash?

Aim: Xen does its best to handle misconfig / faults to get system up
to a usable console

Andy: two separate crash cases:
  1: hypervisor crash:
  - current Xen can reserve memory on boot, load a crash kernel,
    jump into it on a crash: mount root disk, dump logs, reboot
  - is kexec case, and also the safety case for error in the hypervisor

  2: crash of a domain that Xen is starting:
  - can use normal Xen functionality to recover
  - structure in doc supports DRTM measurement of crash handling logic

Stefano: there is some similar need or equivalent in Safety systems
Bertrand: doc should describe what a crash is, what the functionality
can do

* ACTION: update doc to describe proposed crash response functionality

* Terminology: 'recovery' or 'rescue' terms preferred:

- First: better as "crash environment" (not "crash domain")
- Second: "recovery domain""

Bertrand: safety case: reboot to most recent known working config
- on server, reboot to interactive is ok
- make sure domain has sufficient capacity to do both

* ACTION: add definitions and descriptions to the design doc
    - work out where the safety use case fits
    - multiple domains can have control domain permission

* Recommendations on approach for development
 - 40-odd patch series in prototype: too big for one series (!)
 - will work on changes to both x86 and Arm code together

Stefano: sending multiple smaller series is OK: make each testable

* How much common vs. arch-specific?

Andy: aim for common: logic in-line with RISC-V and PowerPC ports
- eg. LCM handling in common; and may require some arch-specific

Christopher: prototype used PV for Hardware Domain, following code
for current most-common dom0; any guidance on PV vs PVH, experience
with PVH dom0?

Roger: PVH dom0 used on FreeBSD; is in GitLab CI and osstest.
PVH use for domU is more common.

Andy: Hardware Domain and Control Domain need clearer definitions

* ACTION: add definitions and descriptions for Hardware, Control,
domain to the design doc

Roger:
- feedback on PCI points: have posted to the list

* Beyond posted docs:

Andy: Bareflank-style setup is relevant: can ensure Hyperlaunch work
aligns and keep use case in mind
eg. case where hypervisor doesn't have scheduler, offloads power mgmt
Rich: seek design input for Hyperlaunch
Eric: invite to next call?

* ACTION: invite Bareflank developers to next call, supply pointer to
Hyperlaunch design docs

* Public development:

Rich: ok for in-development Hyperlaunch code to be public on github?
Christopher + Daniel: most likely yes; can check with project sponsor

--
Christopher