Design Sessions: Difference between revisions

From Xen
Jump to navigationJump to search
(Redirected page to Category:Design Sessions)
Tag: New redirect
 
(33 intermediate revisions by the same user not shown)
Line 1: Line 1:
#REDIRECT [[:Category:Design_Sessions]]
== 2018: Developer and Design Summit ==
==== Architecture ====
* [TODO Reworking x86 Xen, current status and future plan]
* [TODO PCI pass-through with de-privileged QEMU]
* [TODO Resource mapping, PV-IOMMU and page ownership in Xen]

==== Intel Specific ====
* [TODO Intel Processor Trace for Xen hypervisor design discussion]
* [TODO how to support more vCPUs in a HVM guest]
* [TODO NVDIMM Discussion]
* [TODO SGX deep dive and SGX virtualization design discussion]

==== Embedded and Safety ====
* [TODO Dom0less and static partitioning]
* [TODO A Strawman Plan to Make Safety Certification for Xen Easier]
* [TODO Graphic virtualization on Xen]

==== Working Practice, Process, ... ====
* [TODO Testing/Building with Docker/GitLab]
* [TODO (Automated?) Performance Testing in Virtualization]
* [TODO Process changes: is the 6 monthly release Cadence too short, Security Process, ...]

==== Performance ====
* [https://lists.xenproject.org/archives/html/xen-devel/2018-07/threads.html#00017 XenWatch Multithreading Design Session]

==== Security ====
* [TODO Silo mode for extra defence in depth]
* [TODO Panopticon: See no secrets, leak no secrets]
* [TODO What is OpenXT and the Xen Security Community Doing - this was primarily about measured boot and Win10 support]

==== Other ====
* [TODO USB pass-through on Xenserver]
* [TODO From Hobbyist to Maintainer, Why and How]
* [TODO Unikraft: Design and Use Cases]


== 2017: Developer and Design Summit ==
=== Notes ===
'''Intel sessions'''
* [http://markmail.org/message/ibzznuc6c6suow3o Notes from the 5-level-paging session ]

'''ARM Sessions'''
* [http://markmail.org/message/ydwaxnbn6f76inhg Notes from PCI Passthrough design discussion at Xen Summit]

'''Coprocessor Sharing and Stubdoms'''
* [http://markmail.org/message/qz3mtbzypohc7vh2 Notes on stubdoms and latency on ARM]
* [http://markmail.org/message/t7ipyk44gbjvxrqv Shared coprocessor framework followup]
* [http://markmail.org/message/mxqriltr7dt5yr3p SCF configuration followup]

'''PVH (v2)'''
* [http://markmail.org/message/ryvksozgrfefiadh Notes from the PVH toolstack interface session]
* [http://markmail.org/message/v3ks2hkfodip777c Notes from the PVH performance session]

'''Release and Build tools'''
* [http://markmail.org/message/7e2mdpimvrmsppq5 Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling]
* [http://markmail.org/message/kyibfdwfv7plmzuz Notes Design Session: Testing & CI Process and Workflow Improvements, x86/ARM/Embedded Testing, etc. - Does what we do today work?]
Outcomes
* [http://markmail.org/message/y6pzru76ufizz2rv Build tools follow up]
* [http://markmail.org/message/4as7zfl2tfqhpdyo A document for Xen release management ]
* [http://markmail.org/message/lvig3u2gcqt3nwgs A document for Xen release management, v2]

'''Security, Safety'''
* [http://markmail.org/message/h2bjcu47mi5ozxgv Notes of Design Session: Xen Certification in Automotive Industrial]
* [http://markmail.org/message/zxtisdcbh6k7mdr5 Notes for Design Session: Loose ends for becoming a CNA (CVE Numbering Authorities) and other Security Team Operational Questions]
* [http://markmail.org/message/37annnvm7wwygr4j Notes from Design Summit Hypervisor Fuzzing Session ]
Outcomes
* [http://markmail.org/message/lvoapfwg66m7agp7 Scripts to check XSA patch-level on xen trees (xen.git, qemu-xen.git & qemu-xen-traditional.git)]

'''Community'''
* [http://markmail.org/message/ufgy7p3zk7umnuik Notes from Design Session: Solving Community Problems: Patch Volume vs Review Bandwidth, Community Meetings ... and other problems]

=== Sessions Highlighted on the Wiki ===

{{DesignSession
|Project=Graphics Virtualization
|Date=July 11 2017
|Contact=(OpenXT) Rich Persaud, Christopher Clark
|Desc=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?

* Intel GVT-d and GVT-G with local multi-monitor display
* Zero-copy display of guest framebuffers: Intel GVT, ARM with and without IOMMU
** Baboval 2013: http://events.linuxfoundation.org/sites/events/files/slides/Zero-Copy%20Display%20of%20Guest%20Framebuffers%20using%20GEM.pdf
* Display management: GVT, PV-displ, Qubes compositor, OpenXT surfman
* HID virtualization (secure input, seamless mouse-display switching, multi-touch)

SCHEDULE: http://sched.co/AjEV
|Review=
{{comment| Feel free to make suggestions here}}<br>
{{vote|And whether you intend to attend}}
}}

{{DesignSession
|Project=Xen Toolstacks for Server and Edge Use Cases
|Date=July 11 2017
|Contact=(OpenXT) Rich Persaud, Christopher Clark, Chris Rogers
|Desc=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
|Review=
{{comment| Feel free to make suggestions here}}<br>
{{vote|And whether you intend to attend}}
}}

{{DesignSession
|Project=Testing Server and Edge Hypervisors
|Date=July 11 2017
|Contact=(OpenXT) Rich Persaud, Christopher Clark
|Desc=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
|Review=
{{comment| Feel free to make suggestions here}}<br>
{{vote|And whether you intend to attend}}
}}

{{DesignSession
|Project=Design Session: Loose ends for becoming a CNA (CVE Numbering Authorities) and other Security Team Operational Questions -
|Date=July 13 2017
Contact=Lars Kurth, Ian Jackson
|Desc=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 [https://docs.google.com/document/d/17LiK-C3oBFZNpxeihXxkM2Bagn7A2L3Dv1u1ZGZe_TQ/edit google doc])
* Review the scope (currently in a [https://docs.google.com/spreadsheets/d/1wLb37mbxN715rlYD8eKV8htgatDI41noOmQ1H428QX4/edit#gid=0 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'''
* Automated checking of XSAs against releases (see https://xenbits.xenproject.org/gitweb/?p=people/larsk/xen-release-scripts.git;a=summary)
* Usage of RT and issues that has caused => does it work, what to change?

'''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
|Ref=<br>
* xen-devel thread at http://markmail.org/message/zxtisdcbh6k7mdr5
* SCHEDULE at http://sched.co/AjHl
|Review=
{{comment| Feel free to make suggestions here}}<br>
{{vote|And whether you intend to attend}}
}}

== Archive ==
See [[Hackathon_and_Dev_Meetings]]

[[Category:Developers]]
[[Category:Events]]

Latest revision as of 11:02, 9 August 2019

Redirect to:

Retrieved from "https://wiki.xenproject.org/index.php?title=Design_Sessions&oldid=19514"