Recent blog entries for mulix

Two years ago Orna and I embarked on one of the great projects of our lives.

Two years later, it is going splendidly.

<center> </center>

Happy birthday, Yael, my little princess. You fill our lives with joy, every single day.

Syndicated 2008-10-11 06:56:15 from Muli Ben-Yehuda

I'm a-twitter

I was working from home today and didn't have anyone to talk to. So I finally bit the bullet and figured, why talk to *someone*, when I can talk to *everyone*? Hence, muliby on twitter. Leave a comment if you're on twitter.

Syndicated 2008-08-26 15:43:59 from Muli Ben-Yehuda

WIOV '08 CFP

It is my great pleasure to invite all of you to submit papers and participate in the First Workshop on I/O Virtualization (WIOV '08), to be held in conjunction with OSDI '08.

First Workshop on I/O Virtualization (WIOV '08)
December 10–11, 2008, San Diego, CA, USA
http://www.usenix.org/wiov08

WIOV '08 will be held in conjunction with the 8th USENIX Symposium on Operating Systems Design and Implementation (OSDI '08), December 8–10, 2008.

Overview

Over the past decade, the use of virtualization technology has grown rapidly. Moreover, it is being used in a variety of places, ranging from the data center to the desktop. Although this has spurred great advances in processor and memory virtualization in commodity hardware and virtualization software, I/O virtualization has received far less attention. However, both personal computers and servers may perform significant amounts of I/O. For example, efficient virtualization of graphics hardware has presented significant challenges on the desktop and efficient virtualization of network interfaces has limited server consolidation in the data center.

This workshop is meant to provide a forum to discuss challenges of I/O virtualization that span the virtual machine monitor, guest operating system, processor, memory subsystem, and I/O subsystem. In that spirit, we welcome papers that describe new challenges in I/O virtualization and papers that describe novel approaches to solving known problems in I/O virtualization. The final program will consist of both reviewed submissions and invited talks. The invited talks will focus on open problems in I/O virtualization and will be accessible to a broad audience.

Topics of interest include but are not limited to:

* Hardware support for I/O virtualization
* Novel I/O device architectures for virtualization
* Novel software approaches to I/O virtualization
* Software methods for I/O device emulation
* Para-virtualized I/O device driver design for virtualization
* Virtual machine monitors I/O subsystems

Important Dates

Submissions due: September 15, 2008
Notification to authors: October 3, 2008
Final files due: November 3, 2008

Workshop Organizers

Program Co-Chairs

Muli Ben-Yehuda, IBM Haifa Research Lab
Alan L. Cox, Rice University
Scott Rixner, Rice University

Program Committee

Eyal de Lara, University of Toronto
Jun Nakajima, Intel
Renato Santos, HP Labs
Karsten Schwan, Georgia Institute of Technology
Pratap Subrahmanyam, VMware
Leendert van Doorn, AMD
Andrew Warfield, University of British Columbia

Submission Guidelines

Please submit an extended abstract in PDF format through the workshop submission web form, which will be available at http://www.usenix.org/wiov08 soon. The extended abstract should be no more than 4 double-column pages using 10-point type on 12-point leading ("single-spaced"). Figures and references are not included in this 4-page limit.

Syndicated 2008-08-07 02:08:49 from Muli Ben-Yehuda

recent happenings and MMCS 2008 position statement

I'm in lovely Boston this week. Originally I was supposed to attend the Xen Summit North America 2008, MMCS 2008, and USENIX 2008, but I ended up missing the Xen Summit completely and making a just-in-time appearance at MMCS, due to some trouble at home. Thankfully everything is fine now.

At the Xen Summit my colleague Todd DeShane presented our preliminary results of a quantitative comparison of Xen and KVM. I'm sorry I missed the summit, by all accounts I heard it was a pretty fun event.

At USENIX, I presented a poster on our SCIMITAR work which introduces the notion of "virtual memory for I/O devices". It got generally positive feedback, including a few "wow, that's pretty cool" comments. I kept wishing our prototype was at a stage where we could finally have some results, but as I told those who asked, if we had had any results, I would've been presenting a paper, not a poster...

At MMCS, I participated in a panel on "Platform Management---Coordination or Not?", moderated by Intel's Milan Milenkovic. Platform management is a subject that comes up fairly often in my day-to-day work, so it was fun spending some time thinking about it and trying to come up with an appropriate position statement for the panel. The way I see it, the primary function of a panelist is to encourage the audience to think, and the easiest way to do that is to be a bit controversial. A panel where everyone---both panelists and audience---agree on everything, is a dull affair.

Here is my MMCS 2008 panel position statement---paraphrased, not transcribed! For context, you probably want to read the panel description first.

"Hello everyone,

Thank you for inviting me to participate in the panel. When thinking about the questions Milan raised with regards to platform management, I had a bit of a problem coming up with a suitable position statement. As it happens, I either wear or used to wear many different hats. I used to work on real applications. I currently work on operating systems and hypervisors, and occasionally I dabble in computer architecture. I wondered, what kind of insight could I get from each of these perspectives?

From the application writer's perspective, there are three different classes of application writers: those who do not care about the platform at all, those who think they know everything best but actually don't, since they only have localized knowledge, and those that really do know everything best.

From the operating systems developer perspective, you don't get too many kernel developers who don't care about the platform, so we can leave those out. That leaves two classes: those who think they know best, but are wrong since again they only have localized knowledge (think virtual machines), and those who really do know best.

From the hypervisor's developer perspective, well, really, hypervisors are just a new name for operating systems!

From the computer architecture folks perspective, well, they just know everything best. Having said that, they have a whole lot of legacy stuff to support which severely constrains what they can and want to do.

Now, having shared with you all of these perspectives, let me share something else: none of it actually helped me come up with a good answer to the question's Milan raised.

So I tried a different approach. I assume most of you are familiar with the end-to-end argument in system design, which is usually applied to networking. Well, what does the end-to-end argument tell us about platform management? As far as I can apply it, it tells us that we should let each layer do what it knows how to do best. Not a very satisfying answer.

Well, let's try a different approach then. Programming language folks like to say that programming languages should make "the simple things easy, and the hard things possible". And here I think we may have actually hit on something. How does this apply to platform management? The way I interpret it, it means two things. First, that each layer in the system should make sensible decisions on its own. Second---more importantly, and hopefully somewhat controversially---that each layer should provide a "chicken switch".

What's a chicken switch? It's a term you sometimes hear in hardware design. It means that when you have all these new functionality in your design, which is not as well tested (or thought out...) as the old, reliable stuff, you usually enable it (it's new and shiny after all), but you also provide a way of "shouting chicken". A way of disabling the new stuff and going back to the old, proven way of doing things.

By analogy, I claim that the most important feature a platform component can have when it comes to management, is a way for the layer above or below it to tell it to "do nothing, and get out of the way".

Thanks you."

Syndicated 2008-06-26 21:28:28 from Muli Ben-Yehuda

upcoming conference submission deadlines

Still haven't decided which conferences to submit which paper to, except SYSML which is the obvious venue for the follow-on paper to our Vigilant work.

ASPLOS '09: August 1st, VEE '09: August 29, SYSML '08: Sep 26th, EuroSys '09: Nov 7th, HOTOS '09: Jan 13th, 2009.

Syndicated 2008-05-25 22:30:47 from Muli Ben-Yehuda

On Thursday this week I'll be giving a talk at the 2008 Israeli Networking Seminar on "Networked I/O for Virtual Machines: Approaches and Challenges."

Next month I'll be returning to one of my favorite cities in the world, Boston, for the 2008 Xen Summit North America, the Workshop on Managed Many-Core Systems (MMCS) and USENIX ATC.

The Operating Systems Review special issue on research and developments in the Linux kernel is shaping up quite nicely and should be going to the printers soon. All of the accepted papers are good, but some are real diamonds.

Syndicated 2008-05-25 22:17:57 from Muli Ben-Yehuda

Simon L. Peyton Jones, John Hughes, and John Launchbury , Department of Computing Science, University of Glasgow, Scotland, "How to write a great research paper".

Link via Silvia Miksch's excellent page of tips on how to do research.

Syndicated 2008-05-25 21:44:35 from Muli Ben-Yehuda

I spent a couple of pleasant hours today trying to wrap my head around KVM's MMU code. After reading "The Shadowy Depths of the KVM MMU", it suddenly starts to - almost - makes sense.

The tentative agenda for the 2008 KVM forum has been published and is chock-full of awesomeness.

Syndicated 2008-04-27 19:58:44 from Muli Ben-Yehuda

The Charge of the Light Brigade, by Alfred Tennyson

Half a league, half a league,
  Half a league onward,
All in the valley of Death
  Rode the six hundred:
'Forward, the Light Brigade
Charge for the guns' he said
Into the valley of Death
  Rode the six hundred.

'Forward, the Light Brigade!'
Was there a man dismay'd?
Not tho' the soldiers knew
  Some one had blunder'd:
Theirs not to make reply,
Theirs not to reason why,
Theirs but to do and die,
Into the valley of Death
  Rode the six hundred.

Cannon to right of them,
Cannon to left of them,
Cannon in front of them
  Volley'd and thunder'd;
Storm'd at with shot and shell,
Boldly they rode and well,
Into the jaws of Death,
Into the mouth of Hell
  Rode the six hundred.

Flash'd all their sabres bare,
Flash'd as they turned in air,
Sabring the gunners there,
Charging an army while
  All the world wonder'd:
Plunged in the battery-smoke
Right thro' the line they broke;
Cossack and Russian
Reel'd from the sabre-stroke
Shatter'd and sunder'd.
Then they rode back, but not
Not the six hundred.

Cannon to right of them,
Cannon to left of them,
Cannon behind them
  Volley'd and thunder'd;
Storm'd at with shot and shell,
While horse and hero fell,
They that had fought so well
Came thro' the jaws of Death
Back from the mouth of Hell,
All that was left of them
  Left of six hundred.

When can their glory fade?
O the wild charge they made!
  All the world wonder'd.
Honour the charge they made!
Honour the Light Brigade,
  Noble six hundred!

Syndicated 2008-03-22 22:01:11 from Muli Ben-Yehuda

ASPLOS is going quite well so far. There were a few really interesting papers (see below). My talk went well, if I may say so myself... the slides are online.

Papers y'all should read:

Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems - Protecting an application from a malicious OS sounds counter-intuitive, but given a sufficiently smart hypervisor, it can be done. This is another step toward making the OS just another library.

Accelerating Two-Dimensional Page Walks for Virtualized Systems - How to get nested paging to perform.

The Design and Implementation of Microdrivers - Automatically split Linux kernel drivers into a performance critical part (which stays in the kernel) and a non-performance critical part which is moved to user-space.

Syndicated 2008-03-05 18:44:49 from Muli Ben-Yehuda