Design Sessions 2019
- 1 Sessions with published notes
- 1.1 Agreeing priorities for the next year
- 1.2 osstest before push to nonrewinding branch - aka Branch management
- 1.3 Build System gripes
- 1.4 Further defences for speculative sidechannels
- 1.5 Xen Toolstacks
- 1.6 Xen Distros
- 1.7 Live Updating Xen
- 1.8 Virtio
- 1.9 Technical debt in the Xen ecosystem (inc libxc/xenstored discussion)
- 1.10 Rust and Xen
- 1.11 Community Issues / Improvements - Communication, Code of Conduct, etc.
- 2 Sessions without published Notes
Sessions with published notes
Agreeing priorities for the next year
This is an attempt to agree on the top few (we can decide how many) development and community priorities for the next year. We should only include larger feature development (that may cover multiple series) with the aim to help code reviewers to coordinate review time to get these through the review cycle more quickly. Attendees are expected to a) Propose major developments in the works or pipeline b) Vote / provide input on how important these are
For notes, see
osstest before push to nonrewinding branch - aka Branch management
Right now, if a bad commit (that cause osstest test failures) get pushed to staging, they get entangled with other work and have to be fixed or reverted. Most modern CI systems run tests on proposed branches before those branches are pushed to some shared non-rewinding branch. Can we do the same for Xen and osstest ? How ?
For notes, see
Build System gripes
Further defences for speculative sidechannels
The discovery of speculative sidechannels has undermined a lot of the security boundaries that software took for granted. Some defences have already been introduced, but other areas could do with further hardening. Additionally, we should look for ways to reduce the overheads where possible.
At the moment, we have a binary xl, which can be run; and we have libxl, which links against libxc and various other libraries, which must match 100% the hypervisor version. We have python and partial golang bindings for some of these libraries, but these may break and need recompilation when upgrading to a new version of Xen. This session is to discuss what, if anything, to do as a result of this. A couple of options: Make a daemon which links against libxl and exposes that functionality in a backwards-compatible manner Make the Xen ABI fully backwards compatible, so that upgrades to Xen will work with older libraries
Xen is packaged on several different distributions: CentOS, Debian, Fedora, and Arch. This is an opportunity for distro package maintianers (at minimum George Dunlap, who maintains the CentOS Xen packages) and distro package users to get together and talk about best practices and how things can be improved.
Live Updating Xen
Live-Updating Xen is replacing the running Xen hypervisor in-place on a system without guests noticing. This feature does not yet exist - it's very early days to get involved and design the solution. Following up from the talk on Wednesday, we'll use this slot to talk about use-cases, how much and what will be of interest to the community, and design discussions on the feature.
For notes, see
There is an interest on Arm to support virtio on Xen. This would allow us to leverage existing PV protocols (e.g virgil 3d) and offering an easy way for users to migrate to Xen. The topics expected to be discussed during the sessions are: - Transport to be used - How to prevent backend to access all the guest memory - Sketch a plan and potential contributors
For notes, see
Technical debt in the Xen ecosystem (inc libxc/xenstored discussion)
Xen has evolved over time, but there are areas of technical debt which have built up and are getting in the way.
For notes, see
Rust and Xen
Discussing the usage of Rust with Xen. Rust is a safe systems language with a focus on zero-cost abstractions. A low level effort is underway to provide native bindings to the hypercall ABI to allow native simple recompiling of Rust programs as unikernels.
For notes, see
Community Issues / Improvements - Communication, Code of Conduct, etc.
This is a session in which a number of community related issues can should be discussed and agreed, for example - Do we need a Code of Conduct? - How can we make Xen Project more welcoming for newcomers? - How do we communicate better and more effectively on the mailing list - Feedback: we don't set expectations very well (e.g. around cover letters and in other areas) - We struggle with things such as bikeshedding - We don't seem to be good at resolving disagreements effectively (even though we have formal mechanisms in place) - Frequently communication on xen-devel@ comes across as unfriendly: is there a way to do this better? We don't have the same issues on IRC
For notes, see
- https://hackmd.io/jaQAUyLDRDaVY5KNCpqdEg (these need work)
Sessions without published Notes
A Journey through Unikraft's Build System
The purpose of this session is to give a tutorial on how to write Unikraft Makefiles and Configuration files. This task is needed when developing or porting applications or libraries with Unikraft.
Exposing hardware-backed CPU timers to limit overhead from Xen's software timers
Problem to Solve Software-based virtual timers implemented in Xen are a source of overhead and non-determinism for virtualized applications. For some industries and use cases, these observables effects prevent Xen from being used - performance guarantees and determinism trump almost all other matters in some applications. Ryan Thibodeaux and Christopher Clark seek to host a design session to discuss a proposal for exposing hardware-backed CPU timers to guests, with an initial emphasis on Intel CPUs and Linux guests. The approach considered would selectively expose the local APIC timers in each Intel CPU core, thereby allowing Linux guests to directly utilize high-resolution timers in hardware. The proposed approach would likely entail a new guest configuration option that would control access to hardware timers. It is expected that the feature would be available to specific configurations where side-effects and guest features are limited, e.g., CPU pinned guests using the NULL scheduler and without migration support. Attendee Contributions Ryan and Christopher seek feedback and guidance from both the Xen and Linux maintainers. Ryan and Christopher will present an initial approach to expose CPU / hardware-backed timers (likely including patches for both projects). It is expected that the audience will review the design concepts and help to identify risks and limitations of this approach. Ideally, the design session will conclude with a decision on the feasibility of an approach to improve timer performance and identify the configuration options to extend or add in support of this approach. Preparation Ryan Thibodeaux has already submitted a related patch to the Linux kernel project that allows a guest kernel to change (at boot) the minimum timer resolution in the kernel (see https://github.com/torvalds/linux/commit/2ec16bc0fc7ab544f2d405fd4fdd0d717c5ec0c5). This mirrors an existing feature in the Xen hypervisor (the "timer_slop" Xen option).
LivePatch improvements and features
Development plans for LivePatch on Xen: Support for module parameters Additional hooks support Concept of expectations inline assembly patching Replaceable apply/revert actions Fixes and improvements for stacked modules
Xen Adventures in Edge Computing
Since Xen's origin in cloud computing, the bare-metal hypervisor has been applied to desktops, network middleboxes, vehicles, aerospace, accelerator, graphics and other "edge" applications. Vendors have applied Xen in a range of system architectures, for performance, security, safety, reliability, power and other axes of optimization. In long-lived business workflows at the power-constrained edge, domain-specific Xen and guest configurations have different priorities than general-purpose Linux distributions and cloud platforms. As each vendor's product team earns hard-won platform lessons in their domain, how can reusable knowledge be shared with Xen, guest and hardware developers in neighboring domains? Until now, the answer has been fragmentation of the Xen ecosystem, with Xen Summit bridging some gaps. Can we borrow from the anti-fragmentation techniques of the KVM community, including the rust-vmm "building blocks" approach employed by RedHat, AWS, Google and Intel? Can OSS subsets of code, config, policy, build and test infrastructures can be shared by multi-domain, Xen-based embedded products? If you are working with Xen in unusual applications, this session may be of interest.