XPDDS19 Keynote: Xen Project Weather Report 2019 - Lars Kurth, Director of Open Source, Citrix Systems UK Ltd. & Xen Project Chairperson Click here to add to My Sched. https://sched.co/PFWI
In this keynote talk, we will give an overview of the state of the Xen Project, trends that impact the project, see whether challenges that surfaced last year have been addressed and how we did it, and highlight new challenges and solutions for the coming year.
Similar to XPDDS19 Keynote: Xen Project Weather Report 2019 - Lars Kurth, Director of Open Source, Citrix Systems UK Ltd. & Xen Project Chairperson Click here to add to My Sched. https://sched.co/PFWI
Management Information Systems – Week 7 Lecture 2Developme.docxcroysierkathey
Similar to XPDDS19 Keynote: Xen Project Weather Report 2019 - Lars Kurth, Director of Open Source, Citrix Systems UK Ltd. & Xen Project Chairperson Click here to add to My Sched. https://sched.co/PFWI (20)
2024: Domino Containers - The Next Step. News from the Domino Container commu...
XPDDS19 Keynote: Xen Project Weather Report 2019 - Lars Kurth, Director of Open Source, Citrix Systems UK Ltd. & Xen Project Chairperson Click here to add to My Sched. https://sched.co/PFWI
5. 1. All: Register
Verification Code: Chicago2019
2. Session Host: Create Session
Tuesday before 11:00
Wednesday before 15:00
3. All: Rate Sessions
Which sessions do you want to attend?
Check daily and indicate your preference
for new sessions
Thank you to George Dunlap
for putting this together
6. 1. All: Register
Verification Code: Chicago2019
2. Session Host: Create Session
Tuesday before 11:00
Wednesday before 15:00
3. All: Rate Sessions
Which sessions do you want to attend?
Check daily and indicate your preference
for new sessions
4. Admins: Before design sessions
We will run the scheduler ➜ Final schedule for the day
Thank you to George Dunlap
for putting this together
7. Design Sessions are hands-on sessions to solve design, technical,
process and other community problems. They are not presentations.
1. Session Host: Introduce the topics and/or problems you want to solve
You can use a short presentation to do this
If the topic is fuzzy: come up with a list of sub-topics / discussion areas asking the audience
2. Session Host: Nominate a note taker
Ask the audience, or arrange for a colleague to do this
Create notes in https://etherpad.net/ with a name such as xen19-<sessionname>
3. All: Huddle and work together to solve the problem
Tips: raise your hand if you can’t get heard
Ask clarifying questions
Contribute to the discussion
4. Note taker: Writes Notes
After the meeting send etherpad URL to
community.manager@xenproject.org
8.
9. Birthdays
The Xen Project has turned 15
Unikraft is turning 2
Big themes of the last few years are coming to a close
PVH, QEMU-Depriv, …
What is next?
Security Issues (HW and SW)
Remains a big deal and we are still handling the fall-out (e.g. L1TF)
Infrastructure, CI, Testing
Agreed ambitious plans last year and we are making progress
How are we going to complete these and get them widely used?
10. Community and How we Work
Recent discussions at community calls about Best Practice and how we do
things. Would like to make progress at this in a design sessions
Automotive, Embedded and Safety
Made good progress on Features
Set up mechanisms to investigate how Xen can be more easily safety certified
11. Creating a roadmap for the future
Try and agree on a few top priorities for the next release and beyond
Establish community mechanisms in place to do this on an ongoing basis
Design Session: Agreeing priorities for the next year
How do we deal with technical debt?
Primarily affects x86, Arm to a lesser degree
And areas with technical debt where people want to contribute to
Design Session: Do we need one?
12. A better Development Environment
Documentation, tools, CI and testing
Working better together: standards, setting expectations and best practices
Design Sessions:
– Build System Gripe Session
– Xen Project CI Infrastructure v2: where we are, gaps and how to tie it all together
– Community Issues / Improvements - Communication, Code of Conduct, etc.
Changes from contributors that care about safety
Impacts: Documentation, tools, CI, testing and coding standards
Design Sessions:
– FuSa: define the scope in terms of codebase and interfaces
– FuSa: new OSS tools for Xen compliance
13.
14. PVH DomU done with the exception of PCI Passthrough
PVH dom0 is basically completed
– Missing regular OSSTEST
– Missing support for SRIOV
– Linux: some changes to Linux kernel needed
HVM/PVH and PV only Hypervisor
QEMU Deprivilege
– additional improvements
It is not 100% clear what the big new feature themes are: maybe sit
together in a design session at the summit to agree
15. New Website
1 year ago we agreed a vision for improving our CI infra
There has been significant progress (Doug, Wei & Others)
– GitLab CI: https://gitlab.com/xen-project/xen/pipelines
– Enabled and evaluated patchew and patchwork
https://patchew.org/Xen & https://patchwork.kernel.org/project/xen-devel/list/
– Checkpatch/clang-format by EPAM – stuck due to lack of review/input
Need to take this further in the next few days
We had QoS issues in OSSTEST
Need to address this if we care about quality and delivery of releases
Need to diversify ownership: it’s a single point of failure
17. Xen-devel@
:patchew
or patchwork
Gitlab CI
submit only review
if tests pass
Fetches series/patches
create tmp
git tree
Build (distros, configs, compilers)
& smoke tests (x86 only for now)
Tested-by: bot
or Test-Failed-by: bot
commit as now
18. Almost all pieces are in place
There seems to be broad agreement that this is the right way to go
There is likely some impact on trees
There are some concerns about details
Doug has a talk which covers some of this in more detail
And we need to plug some gaps, as :patchew and patchwork have some gaps
Also see: https://markmail.org/message/4ur5mqx2yruhvfcj
Coding styles and other checker hooks
There would be an opportunity to integrate other checking tools, e.g.
– Automatic code-style checking
Patches to clang-format have been developed by EPAM, but need testing by committers
– Maybe there are certain files in tree, that if touched imply a docs/test change is needed
Could experiment with such ideas to see if a hook could suggest hints
19. Community Calls
Monthly meeting to coordinate issues: 1st Thu of each month @ 15:00 UTC
Info: https://wiki.xenproject.org/wiki/Community_Call
Meetings have been very productive
Topics Raised
Project Management: unblocking series, etc.
Information sharing
Improving Developer Docs
Community Issues/Improvements recently discussed
– Code of Conduct / Best Practice
– Improving coordination: proposal is to track and actively manage important series in a
release
20. New Functionality
Tiny Arm Config (<50 KSLOC), Dom0Less
In progress: OP-TEE, virtio, power management, …
Safety Workshop and FuSa SIG
March 2-day workshop with 30 attendees from community and safety certification
experts to verify feasibility
Set up FuSa SIG to understand what is needed and make progress
MISRA C
Failed experiments in Q4’18 and Q1
Tried this without understanding needs, how to justify non-compliance,
inadequate tooling (didn’t know what would fix an issue) and lack of access to
spec
21. Community Reps and Support
Lars, George, Andrew, Julien, Wei and
Stefano
Kate Steward as observer/
advisor
Vendors with investment in Xen
Vendors with product interestSafety Assessors
22. Goals
Establish feasibility and to create a
plan on what would need to be done to
achieve
– Define scope and route
– Safety Management System
– Documentation (Requirements, Designs,
Architecture, …)
– Verification Tests
– Community Interactions and Processes
– Process Automation Tools
There must be a benefit for the wider
community
Members
Community reps: Lars (community) &
George (committers)
Vendors: XILINX, EPAM, Arm,
Renesas, Resiltech (for testing), Linux
Foundation
Safety Certification Assessors:
Observers: TUV, MIRA, Exida
Supporters: Rina (Strategy,
Technical), Bugseng (Tools & MISRA)
23. A small, well defined-subset such as Xen/Arm is safety certifiable
– IF artifacts generated during V-model/waterfall SW development exist: requirements,
architecture & designs docs, tests: “unit”, integration, system/requirements
– IF codebase complies with defensive coding practices (e.g. MISRA C subset)
To get there, we need
– Certification scope, standards for documentation, testing and traceability capability
and tools which make maintaining this easy
– Investment in analysis, retrofitting artefacts, maintenance and tools
There is some, but not enough
– Minimize the impact on up-stream & community buy-in
– Infrastructure and advice from assessors to support community
– Currently working through: analysis, investment, scope and some specific areas
@the summit: want to more clearly get a sense of what could be acceptable to YOU