- Call membership (new organisations to invite, +/- representatives from existing organisations, etc.
- Review outstanding ACTION items.
- Current technical challenges.
- Latency of physical interrupts to Hypervisor
- Coordination on current and future work, e.g. planned development activities for next release(s), roadmap items
- Xen 4.2 release status (Ian C)
- Xen 4.3 planning, time lines, what people are working on (Ian C)
- Community news, activities.
- XenSummit CFP deadline (Lars)
- Security process lessons learned (Ian C)
- Should we be more public about the meeting outcome (i.e. do we have public minutes somewhere) (Lars)
- Chair: Ian Campbell (committer)
- Secretary: Lars Kurth
- Boris Ostrovsky, Ian Pratt (Xen.org chairman), Jan Beulich (committer), Jason Douglas, Jun Nakajama, Konrad Rzeszutek Wilk, Olaf Hering, Sheri Flores, Simon Rowe (standing in for James Bulpin)
- Others: excused this time
Latency of physical interrupts to Hypervisor (Jun N)
- The interrupt path in Xen has a higher latency compared to vanilla Linux
- This is independent of PVOPS Kernel or classic Xen Kernel
- Order of magnitude is about 20-30 microseconds
- It appears that there is room for optimization and that we should have a discussion about this. Intel is planning to look into whether there is too much code on the codepath as part of debugging.
- Simon: IRQs & MSIs - Legacy has rather bad latency. Andy Cooper is currently investigating
- Konrad: PVOPS is not doing a fast ACK - an area of extra improvements for PVOPS (note: was fixed after meeting)
Coordination on current and future work
Xen 4.2 release status (Ian C)
- Release candidates should be starting in 2-3 weeks. No hypervisor blockers currently, only tools blockers
- Typically we get 6-9 RC's: this would give us a release date of August (close to XenSummit)
- We are in good enough shape to start cleaning up the feature list of http://wiki.xen.org/wiki/Xen_4.2 - Lars start doing this
- We all agreed that the release cycle was too long
- Generally the consensus was that the 4.2 release cycle was too long. This happened due to lack of ownership.
- The consensus was that we need a discussion on how to do this better: should have a discussion with agreements at the dev meeting before XenSummit. The Linux model was briefly raised but doesn't sound right. Ideally we’d have 9 month release cadence (maybe less). We probably need to be more formal about this and have owners for a release (as well as maintenance releases). We will need volunteers though: Jan and George volunteered
- Jan: Maintenance releases should follow a fixed heartbeat of 3 months. Have not quite achieved this: we had no predictable cadence
Xen 4.3 planning, time lines, what people are working on (Ian C)
- George Dunlap volunteered to act as "release manager/owner" for Xen 4.3
- Lars to schedule a session at the Dev meeting at XenSummit
- George will start reaching out to collect bigger TODO items after RC's and start planning
XenSummit CFP deadline (Lars)
Reminder: XenSummit CFP ends on June 15th, see http://xen.org/community/xensummit.html
Lars secured space for invite owner Developer meeting before XenSummit. Send out instructions and communicate.
Security process lessons learned (Ian C)
Should we be more public about the meeting outcome
- Need to balance open and frank discussion amongst the group vs. need for transparency
- Lars put the following motion to a vote:
- Send meeting notes to the group first **Group is allowed to request for areas not to be published publicly (as to not stifle important discussion)
- Result of vote: motion agreed
||Discuss IRQ's and MSIs with MSIs and get Andy Cooper talking to Jun on xen-devel
||Start cleaning up Xen 4.2 feature list such that it is in good shape when we go into Xen 4.2 RC's
||Ping Keir re maintenance releases. The last RC's of maintenance releases is a few weeks old.
||Done, RC2's published 18/6
||Schedule discussion on Xen Release and Maintenance cycle for Xen Dev Meeting at XenSummit
||Done, see (1)
||How do we evolve blkback? Raise on xen-devel and set up a meeting on how to approach this problem
||Communicate info re dev meeting at XenSummit and put together invite list
||Done, see 
||Future X32 work: Don to make a more detailed proposal on the mailing list. Also need to engage distros to gage impact.
||Performance tooling: Konrad to summarize what is available on xen-devel. Lars to summarize on wiki.
||Done, see  & Xen Profiling: oprofile and perf