CS848 Paper Review Form - Fall 2006

Paper Title:

Author(s):

1) Is the paper technically correct?
 [X] Yes
 [ ] Mostly (minor flaws, but mostly solid)
 [ ] No

2) Originality
 [ ] Very good (very novel, trailblazing work)
 [X] Good 
 [ ] Marginal (very incremental)
 [ ] Poor (little or nothing that is new)

3) Technical Depth
 [ ] Very good (comparable to best conference papers)
 [X] Good (comparable to typical conference papers)
 [ ] Marginal depth
 [ ] Little or no depth

4) Impact/Significance
 [ ] Very significant
 [X] Significant
 [ ] Marginal significance.
 [ ] Little or no significance.

5) Presentation
 [X] Very well written
 [ ] Generally well written
 [ ] Readable
 [ ] Needs considerable work
 [ ] Unacceptably bad

6) Overall Rating
 [ ] Strong accept (very high quality)
 [X] Accept (high quality - would argue for acceptance)
 [ ] Weak Accept (marginal, willing to accept but wouldn't argue for it)
 [ ] Weak Reject (marginal, probably reject)
 [ ] Reject (would argue for rejection)

7) Summary of the paper's main contribution and rationale
   for your recommendation. (1-2 paragraphs)

This paper proposes and implements a virtual machine monitor called Xen. It also describes 
what work need to be done in order to port a commodity operating system such as Linux, 
Windows XP, and netBSD to Xen¡¯s paravirtualized x86 environment. The paper presents a detailed
design of the VMM by separately showing how to implement each of Xen¡¯s subsystems. In order to
show the performance of Xen the paper presents a thorough system performance evaluation. From 
the benchmarks, the charts, and the tables we see Xen is excellent comparing to other approach 
of virtualization in terms virtualization overhead.

The paper is well written and the organization is clear. The paper uses charts to effetely 
illustrate its design. The system evaluation is thorough and the results are empirical. Overall
it is a piece of solid work.     

8) List 1-3 strengths of the paper.  (1-2 sentences each,
identified as S1, S2, S3.)

S1: Xen uses BVT algorithm for CPU scheduling to minimize the virtualization overhead.

S2: When network a package comes, Xen requires the guestOS to exchange an unused page frame instead 
of the standard package copying between Xen and the guestOS.

S3: The paper is well written, the organization is quite clear.

9) List 1-3 weaknesses of the paper (1-2 sentences each,
identified as W1, W2, W3.)

W1: The disk image used for Xen is unclear to me.

W2: Need to modify OS to port into Xen¡¯s virtualization environment.

10) Detailed comments for authors.

I have comment on the I/O ring approach to transfer data between Xen and the guestOS. From Figure 1 
on the paper, we can see the architecture design of Xen and its relationship with all the guestOS: 
One domain0 interface to all guestOSs. When one guestOS tries to access a hard drive for example, 
it needs to submit the access request the ring where all the other guestOS submit its requests to.
Therefore, one guestOS need to wait for the other guestOS and there is no scheduling among the 
requests. Even though the authors claim performance isolation in Xen, I think the that is for CPU 
scheduling among guestOSs, not for the disk IO part.

Also Xen requires modify guest operating system to be ported. That is a big headache for kernel developers. 
For system like Linux, its kernel update pretty often. It is hard to use Xen booting with the new kernel. 
I think it would be nice if Xen could develop a tool that automatically insert hypervisor instructions and 
we can use it when compiling the Linux kernel.