Monthly Archives: June 2011

Xen.org upcoming events

Dear community members. You may have noticed that it has been a little quieter than usually on the blog. One of the reasons is that I have been very busy preparing a number of events. I thought, I’d give you a quick update.

OSCON, July 25-29

Xen.org will be at OSCON this year. OpenStack and Xen will give a joint talk called Achieving Hybrid Cloud Mobility with OpenStack and XCP, on Thursday the 28th at 2:30 pm. If you happen to be at OSCON, why not drop by our booth. Ewan Mellor and Jeremy Fitzhardinge will also be at the booth. Personally, I will also be attending the Community Leadership Summit the weekend before OSCON. If you are as well, drop me a line.

XenSummit North America, Aug 2-3

Last week I published the XenSummit line-up. A big thank you to our Program Management Committee for selecting the talks. I am particularly proud that XenSummit is the first event at the newly built Citrix Conference Center, that we could get Mark Templeton to open the summit and I am also excited about the Amazon keynote. I should be able to confirm the Amazon keynote speaker, the talk with abstract very soon. Next week, Todd Deshane will be publishing the abstracts of the talks on the XenSummit event page. Don’t forget to register if you are coming. The price for registration will be $125 before July 11, $150 after.

Silicon Valley Linux User Group, Aug 3

One of our speakers will update the Silicon Valley Linux User Group on what’s been happening with Xen on Aug 3. As SVLUG has not yet published their meeting agenda, I won’t do this here either. Check out the SVLUG meeting page for more information.

Xen Hackathon, Munich, 13-15 September

Fujitsu will be hosting a 3 day Hackathon at their offices in Schwabing, Munich. You can get the exact address of the event and hotel information on the wiki page. Approximately half of the available spaces have been allocated already: if you do want to attend, send Jürgen or me an RSVP. Also note that the Oktoberfest starts on the weekend after the Hackathon: don’t leave booking your flight and hotels too late.

Later this year
I am also working on Xen Summit Asia and Xen presence at LinuxCon Brazil and USENIX LISA. I will be able to publish more information in the next few weeks.

Xen Summit 2011 Agenda and Speaker Lineup

As you all know, I do not normally write on the Xen.org blog; any blog for that matter. Lars asked me to announce the XenSummit line-up and how could I say no, given the quality of content and the effort that has gone into this year’s XenSummit. I am very pleased that the event is sponsored by Amazon Web Services and Citrix and hosted at the Citrix Silicon Headquarters in Santa Clara, CA.

Rather than list the program here, I’d like to share my personal highlights with you folks:

  • Amazon’s technical keynote : more details will follow soon
  • Konrad Wilk’s (Oracle) Linux PV-OPS Update where Konrad will share with us what has gone into Linux  3, the remaining challenges and how we are aiming to solve them
  • As usual, there will be updates on Xen projects. This year these should be particularly exciting as we have been working on building momentum for Xen ARM and are working on getting XCP packages into Debian and Ubuntu.
  • We will also have lots of talks updating us on the latest research and tell us how Xen and XCP are used within the community. To name a few: Disaggregated Xen by Patrick Colp (UBC), Redesigning Xen Memory Sharing Mechanism by Jose Renato Santos (HP Labs), Evaluation and enhancement to memory sharing and swapping in Xen 4.1 by Xiaowei Yang (HUAWEI) and many more.
  • This year there will also be some changes: we will have lightning talks before the lunch breaks, followed by lunch-time BoFs and discussion for community members who didn’t get their talks accepted.

You can find the full line-up, details on how to register, the exact address and information about hotels on the XenSummit portal.

As you may have seen in the press, I am changing jobs and will be working for Bromium as co-founder and SVP. As is often the case in open source, I will stay very much involved with Xen as part of my new role, Xen.org and will remain chairman of Xen.org.

Ian Pratt
Chairman of Xen.org

Sagar Kadam: Porting Unix libc to Xen PV

This is a guest blog post by Sagar Kadam, one of our Google Summer of Code students. Sagar’s GSoC project is called Porting Unix libc to Xen PV. Please welcome Sagar into the community.

Hello all; I am Sagar Kadam from NYU Poly where I am pursuing my MS degree in Computer Sciences. This is my first year in GSoC: for that matter my first ever experience of working with any open-source project. My university is situated in the city of New York, a city that never sleeps (which many claim is because of bedbugs). My hobbies involve biking and cooking.

This summer I am porting Unix libc to the Xen para-virtualization platform of mini-os, with support of my mentor Ian Jackson. As of now the project uses newlib for all the C library functions. But newlib needs to be replaced with a cleaner and more functional POSIX compliant C library. Also, the new C library should make porting embedded applications such as qemu(-dm) to Xen much easier.

I have started with OpenBSD project’s C library implementation and am writing functionality for some basic syscalls. The syscalls which are required on priority (like write, read, etc) will be implemented first. These calls use hypercalls to communicate with Xen. Some small applications will be written/ported to test that these are functional (or how much). I will then move on to further syscalls. The target of the project is to make the libc implementation as complete as possible and porting a few embedded applications.

The code can be found at ragas/Porting-libc for anybody to read and comment and will be contributed to Xen.

http://www.poly.edu/

Xen 4.1.1 maintenance release available

We are pleased to announce the availability of the Xen 4.1.1 maintenance release, the first maintenance release of the Xen 4.1 series. The release can be downloaded from the download pages.

Xen 4.1.1 sports the following changes:

  • Security fixes including CVE-2011-1583 CVE-2011-1898
  • Enhancements to guest introspection (VM single stepping support for very fine-grained access control)
  • Many stability improvements, such as: PV-on-HVM stability fixes (fixing some IRQ issues), XSAVE cpu feature support for PV guests (allows safe use of latest multimedia instructions), RAS fixes for high availability, fixes for offlining bad pages and changes to libxc, mainly of benefit to libvirt
  • Compatibility fixes for newer Linux guests, newer compilers, some old guest savefiles, newer Python, grub2, some hardware/BIOS bugs.

For those yet to make the jump to the Xen 4.1 series, we have also made available Xen 4.0.2, a maintenance release in the Xen 4.0 series making available a subset of the fixes listed above.

Linux 3.0 – How did we get initial domain (dom0) support there?

About a year ago (https://lkml.org/lkml/2010/6/4/272) my first patchset that laid the ground work to enable initial domain (dom0) was accepted in the Linux kernel. It was tiny: a total of around 50 new lines of code added. Great, except that it took me seven months to actually get to this stage.

It did not help that the patchset had gone through eight revisions before the maintainer decided that it he could sign off on it. Based on those time-lines I figured the initial domain support would be ready around 2022 :-)

Fast-forward to today and we have initial domain support in Linux kernel with high-performance backends.

So what made it go so much faster (or slower if you have been waiting for this since 2004)? Foremost was the technical challenge of dealing with code that “works” but hasn’t been cleaned up. This is the same problem that OEMs have when they try to upstream their in-house drivers –
the original code “works” but is a headache to maintain and is filled with #ifdef LINUX_VERSION_2_4_3, #else..

To understand why this happens to code, put yourself in the shoes of an engineer who has to deliver a product yesterday. The first iteration is minimal – just what it takes to do the the job. The  next natural step is to improve the code, clean it up, but .. another hot bug lands on the engineer’s lap, and then there isn’t enough time to go back and improve the original code. At the end of day the code is filled with weird edge cases, code paths that seemed right but maybe aren’t anymore, etc.

The major technical challenge was picking up this code years later, figuring out its peculiarities, its intended purposes and how it diverged from its intended goal, and then rewriting it correctly without breaking anything. The fun part is that it is like giving it a new life  – not only can we do it right, but we can also fix all those hacks the original code had. In the end we  (I, Jeremy Fitzhardinge, Stefano Stabellini, and Ian Campbell) ended cleaning up generic code and then alongside providing the Xen specific code. That is pretty neat.

Less technical but also important, was the challenge of putting ourselves in the shoes of a maintainer so that we could write the code to suit the maintainer. I learned this the hard way with the first patchset where it took good seven months for to me finally figure out how the maintainer wanted the code to be written – which was “with as few changes as possible.” While I was writing abstract APIs with backend engines – complete overkill. Getting it right the first time really cut down the time for the maintainer to accept the patches.

The final thing is patience – it takes time to make sure the code is solid. More than often, the third or fourth revision of the code was pretty and right. This meant that for every revision we had to redo the code, retest it, get people to review it  – and that can take quite some time. This had the effect that per merge window (every three months) we tried to upstream only one or maybe two components as we did not have any other pieces of code ready or did not feel they were ready yet. We do reviews now on xen-devel mailing list before submitting it to the Linux Kernel Mailing list (LKML) and the maintainer.

So what changed between 2.6.36 (where the SWIOTLB changes were committed) and 3.0 to make Linux kernel capable of booting as the first guest by the Xen hypervisor?

Around 600 patches. Architecturally the first component was the Xen-SWIOTLB which allowed the DMA API (used by most device drivers) to translate between the guest virtual address and the physical address (and vice versa). Then came in the Xen PCI frontend driver and the Xen PCI library (quite important). The later provided the glue for the PCI API (which mostly deals with IRQ/MSI/MSI-X) to utilize the Xen PCI frontend. This meant that when a guest tried to interrogate the PCI bus for configuration details (which you can see yourself by doing ‘lspci -v’) all those requests would be tunneled through the Xen PCI frontend to the backend. Also requests to set up IRQs or MSIs were tunneled through the Xen PCI backend. In short, we allowed PCI devices to be passed in to the Para Virtualized (PV) guests and function.

Architecture of how device drivers work in Xen DomU PV

The next part was the ACPI code. The ACPI code calls the IRQ layer at bootup to tell it what device has what interrupt (ACPI _PRT tables). When the device is enabled (loaded) it calls PCI API, which in turn calls the IRQ layer, which then calls into the ACPI API. The Xen PCI (which I mentioned earlier) had provided the infrastructure to route the PCI API calls through – so we extended it and added the ACPI call-back. Which meant that it could use the ACPI API instead of the Xen PCI frontend, as appropriate – and viola, the interrupts were now enabled properly.

Architecture of how device drivers plumb through when running in Dom0 or PVonHVM mode.
When 2.6.37 was released, the Linux kernel under the Xen hyper-visor booted! It was very limited (no backends, not all drivers worked, some IRQs never got delivered), but it kind of worked. Much rejoicing happened on Jan 4th 2011 :-)

Then we started cracking on the bugs and adding infrastructure pieces for backends. I am not going to go in details – but there were a lot of patches in many many areas. The first backend to be introduced was the xen-netback, which was accepted in 2.6.39.  And the second one – xen-blkback – was accepted right after that in 3.0.

With Linux 3.0 we now have the major components to be classified as a working initial domain – aka – dom0.

There is still work though – we have not fully worked out the ACPI S3 and S5 support, or the 3D graphics support – but the majority of the needs will be satisfied by the 3.0 kernel.

I skimped here on the under-laying code called paravirt, which Jeremy had been working tirelessly on since 2.6.23 – and which made it all possible – but that is a topic for another article.

XenSummit Update

XenSummit North America is approaching: the Call For Participation has closed and we had our first Program Management Committee. We have many good submissions and we started accepting talks: unfortunately some talks will have to be rejected. I am also very excited about the keynote, but it will be more exciting if I let you in the dark for a little longer. I aim to publish the XenSummit program in about two weeks.

Location

I am also pleased to announce that XenSummit will be held at the Citrix Executive Briefing Centre and that XenSummit is the first event to be held there. The address is 4980 Great America Parkway, Santa Clara, 95054 CA, USA. The closest hotels are the Santa Clara Marriott and Hilton Santa Clara. As usual, we will charge a small nominal fee to cover for some of the costs. I will know the exact amount next week and will open registration around then as well.

Calling Xen Developers

We are also considering to hold a Xen.org developer meeting on Aug 4 to allow the community to work on project ideas, code, demos and designs. Let us by next week if you are interested in attending by filling out this poll. If more than 25 people sign up, we will hold the meeting.