Design Sessions 2017

From Xen
Revision as of 10:43, 9 August 2019 by Lars.kurth (talk | contribs) (Created page with " == 2017: Developer and Design Summit == === Notes === '''Intel sessions''' * [http://markmail.org/message/ibzznuc6c6suow3o Notes from the 5-level-paging session ] '''ARM...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search


2017: Developer and Design Summit

Notes

Intel sessions

ARM Sessions

Coprocessor Sharing and Stubdoms

PVH (v2)

Release and Build tools

Outcomes

Security, Safety

Outcomes

Community

Sessions Highlighted on the Wiki

Graphics Virtualization

Date of insert: July 11 2017;
Technical contact: (OpenXT) Rich Persaud, Christopher Clark
Description: GPU virtualization is used in Server VDI, Automotive, Desktops and Laptops. GPU vendors have different approaches to virtualization of 3D graphics (NVIDIA GRID, AMD MxGPU, Intel GVT, Imagination PowerVR OmniShield), while software-based graphics virtualization may not support modern video and user interface animations. Gaming is one of the few growth areas for PCs and CAD can be done via remote desktop. What are current best practices for Xen users and developers to achieve high-performance 3D graphics on Windows, Linux and Android? Is KVM better than Xen for graphics virtualization? SCHEDULE: http://sched.co/AjEV
Outcomes: Not specified, project outcomes
Ref: Not specified, link(s) to mailing list discussion or other references
Peer Review Comments
Pictogram voting comment 15px.png  Feel free to make suggestions here

Pictogram vote 15px.png And whether you intend to attend:


Xen Toolstacks for Server and Edge Use Cases

Date of insert: July 11 2017;
Technical contact: (OpenXT) Rich Persaud, Christopher Clark, Chris Rogers
Description: Many Xen toolstacks have come and gone. Libxenlight was created to provide a common base layer upon which higher-level toolstacks could be built. What is the roadmap for libxenlight to meet the needs of servers, local/enterprise managed clients, OTA update for embedded and mobile devices, unikernels, containers and automated testing? Can we reduce duplication among libvirt, xapi (Ocaml), xenrt (Python) and OpenXT (Haskell) toolstacks? Can Xen management tools compete with DevOps expectations set by the fast-moving container ecosystem?
  • LibXL
    • configurable build (equivalent to hypervisor Kconfig)
    • error handling: map error messages to numeric codes
    • Configuration file for stub domains: Mini-OS, Linux (GPU/NIC PT, CD), rumpkernel
    • State management: multiple LibXL clients per host
  • CoreOS rkt and Xen
  • Toolstack Service VMs
  • Xenstore isolation: options between 1/host and 1/VM?
SCHEDULE: http://sched.co/AjHv
Outcomes: Not specified, project outcomes
Ref: Not specified, link(s) to mailing list discussion or other references
Peer Review Comments
Pictogram voting comment 15px.png  Feel free to make suggestions here

Pictogram vote 15px.png And whether you intend to attend:


Testing Server and Edge Hypervisors

Date of insert: July 11 2017;
Technical contact: (OpenXT) Rich Persaud, Christopher Clark
Description: Virtualization increasingly depends on hardware support, while hardware diversity continues to increase. At present, common feature configurations are tested and given first-class support. Other configurations imply expert mode and private testing. Derivative projects also carry patches that may not be acceptable to upstream Xen, but are common to edge (client, embedded) use cases. Can downstream projects contribute test capacity for non-server configurations of Xen?

These test cases are relevant to OpenXT:

  • Xen feature subsets (Kconfig)
  • GPU passthrough/virtualization with local display: Linux, Windows (USB video capture)
  • Measured Launch (Intel TXT, AMD SVM, TPM 1.2, TPM 2.0)
  • Inter-VM communication: libvchan, V4V
  • Stub domains: Mini-OS, Linux
  • Driver domains: network, USB
SCHEDULE: http://sched.co/AjGk
Outcomes: Not specified, project outcomes
Ref: Not specified, link(s) to mailing list discussion or other references
Peer Review Comments
Pictogram voting comment 15px.png  Feel free to make suggestions here

Pictogram vote 15px.png And whether you intend to attend:


Design Session: Loose ends for becoming a CNA (CVE Numbering Authorities) and other Security Team Operational Questions -

Date of insert: July 13 2017 Contact=Lars Kurth, Ian Jackson;
Technical contact: Not specified, project contact
Description: The Xen Project has in-principle agreement to become a CVE Numbering Authority. However to do this, we need to define the scope of the CNA. A number of have worked on this, but we need some community inout.

Consolidate Security Coverage Documents Consolidate security coverage documents where possible (we have a proposal). Specifically

  • Review the proposal (currently in a google doc)
  • Review the scope (currently in a google doc) - this may involve clarifying the supported status of some components
  • Once we have agreement, we basically just need to document the outcome, publish it and get the process started.

Other Operational Issues

Possible/Proposed Process Changes?

  • Bundling of issues / once every other week or monthly XSA publication?
  • Include maintainers on pre-disclosure when affected and not on security team
Outcomes: Not specified, project outcomes
Ref:
Peer Review Comments
Pictogram voting comment 15px.png  Feel free to make suggestions here

Pictogram vote 15px.png And whether you intend to attend: