TCT Meeting/June 2013 Minutes

Attendees

• Andres Lagar-Cavilla
• Boris Ostrovsky
• Daniel De Graf
• Don Dugger
• James Bulpin
• Jun Nakajima
• Konrad Rzeszutek Wilk
• Lars Kurth
• Matt Wilson
• Olaf Herring
• Sherry Hurwitz
• Ian Campbell

Review ACTIONS

• Nested HVM: Don: thread didn't happen but work is on going. Sherry: Same. Little bit of testing, no list of issues. ACTION: Carried over.

• Linux maintainers. James has agreement from kernel team for David Vrabel to assist, being written into XS resource plan. Konrad has posted a list and had a discussion with David. (DONE) ✓

Technical Challenges

• Coverity: Konrad: ~2 years ago someone wanted to run coverity on Xen but at the time the links with Citrix was too close to qualify. Should revisit. How to handle any issues it finds, in particular security issues. Anyone with an OSS Coverity account can see all OSS Coverity results, Konrad's account (free) doesn't seem to be able to hide security issues.

 Action Konrad: to approach Coverity about the free service and ask about security issues.

Matt: If the policy of Coverity is to not allow security issues to be hidden for a period of time should explore other options.

Lars: Could evaluate the paid options in this case.

• ABI around CPU enumeration. Need to know VCPU ID for PVHVM hypercalls. Currently inferred from BIOS tables, easy to get wrong. Could use an enlightened interface.

Ian: If there is an existing suitable interface just need to add a comment locking it down. Does one exist?

Matt proposed that using DOMID_SELF would be appropriate in many cases but that is a significant interface change which would require a feature flag.

Would be better to use an existing interface. BIOS tables may be suitable but Konrad has seen races. Konrad cannot currently reproduce them but will keep trying.

This is a PVHVM only issue since PV and PVH use PV interfaces.

Sherry: Any observed any perf regressions on 4.3 with domU (particularly HVM RHEL or CentOS 6.4).

James: XS hasn't observed it. But CentOS 6.4 can detect the hyperV flag and try and use the viridian clocksource which can cause boot failures, more severe than a perf regression.

Matt: Issues with non-ideal clocksources, e.g. HPET. Also some RTC clock changes in 4.3 which made Windows installs very slow. Resolved now. Suggested using xentrace, e.g. more vmexits.

Sherry: Have been looking at clocksources and experimenting with those. Will continue to look into it.

• VCPU PV clock in userspace: Jan reenabled these on h/v side, does anyone use these? Need Linux side patches to make use in userspace, old patches from Jeremy exist. Some stuff went in for the equivalent KVM feature, Xen stuff remains TBD.

Jan:Our kernel does now.

Konrad: Thanks! And how does it perform? Is there noticeable differences?

Jan: As this heavily depends on what user mode actually does, I didn't go find a workload that would surface this most heavily. I don't see why if it helps KVM or VMWare or whatever it was that go it enabled first, why it should help us in similar ways. All I know is that it gets used and works (by way of having seen boot failures when I still had a trivial oversight in the patches).

• Windows 8: Jun asked how effective viridian enlightenments are. Matt described them as "a must have": they make an extreme performance improvement and also avoid bluescreens (hangcheck) in certain configurations.

Ian: We just enable viridian but not many enlightenments, do we need to add new enlightenments? Think we are OK.

PV driver support:

Jun: Each distro has its own. Matt GPLPV drivers for Windows. James: Citrix Windows PV drivers are now WHQL signed for Windows 8.

Are working on known interop issues with upstream Xen.

Andres and Matt both have a patch queue for Citrix drivers on upstream Xen.

• VirtIO on Xen: Jun has tried it but performance is not good. Only qemu side backends, so miss optimisations like mac-vtap etc. Was a GSoC project a few years ago which made it work for HVM guests but PV guests were not done.

Jun: Should we continue with front/back model? Or reuse virtio. Frontend exists e.g. for Windows. Is used by other hypervisors, typically Linux hosts. Virtio may not be able to evolve with some of the ideas. Also harder to deprivilege with virtio.

Andres about virtio : qemu thinks it has direct access to the whole RAM of the VM, which doesn't mesh well with the Xen model of mapping (grants or xc_map_foreign_bulk). In particular, doesn't mesh well at all in a driver domain environment.

AFAWK nobody is working on virtio on Xen.

Coordination on current & future work

• Post 4.3 release: Konrad -- what pending patches are there.

Matt: Has guest NUMA, needs libxl bits.

Lars: There was a discussion at hackathon re shortening cycle

 Action Lars: to post about this (done, see [1]) ✓

George has volunteered to release manage again.

• PVH: Konrad: Cutting down to domU only to get something in for 4.4

Community news, activities

• Lars: Xen 4.3 contribution stats [2] & [3]

• Lars: Change name of meeting to something shorter, after discussion decided on: "Technical Coordination Team (TCT)"

• Lars: Papers for LinuxCon and LPC (September), submission deadline is Monday.

• Google Summer of Code: We were not accepted this year. Lars is trying to find out why.

• GNOME Programs Women's Outreach Program, 2 interns starting June 17th.