Re: Re-design the architecture of Xen

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, May 23, 2011 at 04:39:37AM -0700, henanwxr wrote:
> http://xen.1045712.n5.nabble.com/file/n4418793/6.bmp We have researched
> virtualization for several years, with the reference of Xen, we have design
> a new VMM architecture called Cooperative model VMM，and have implemented a
> prototype system.
> We present its principle and part of details here.
> 
> 
> Part1 motivation
> 
> 
> B. Domain0 problems
> Domain0 has several features: 

Features or disadvantages?
> 	Running modified operating system. 

What does 'modified' mean?

> 	Running on processor with privilege level 1 
> 	Running in a form of virtual machine
> 	Single system managing hardware

Right, but that does not have to be the case..
> These features of Domain0 bring the following issues:
> 1) tight coupling
> >From a performance point of view, the coordination of Domain0 and VMM (such
> as: hypercall), event channel and IO ring can improve virtualization
> efficiency, which, however, requires more modification of guest operating
> system. Also, VMM needs to provide the corresponding interface. The tight

I am still lost what you mean by 'more modification' ?

> coupling formed between Domain0 and VMM results that VMM implementations
> must take third-party system characteristics into account, design is lack of

such as?
> independence and flexibility. 
> 2) privilege level switch
> Domain0 is running on the processor with privilege level 1, context switch

Not neccesarily.

> from the VMM to Domain0 will trigger processor privilege level switches. If
> operation of this type is more frequent (such as IO request operation for a
> virtual machine), it will result in larger processor overhead, impacting the

I think you are referring to sysctl. That can be eliminated by having
a 32-bit OS.

> performance of virtual machine.
> 3) overhead of management
> Operating as a virtual machine, Domain0 needs VMM to provide appropriate
> virtual machine managing interface, such as: creation, resource allocation,
> scheduling, and destruction, etc., the resulting administrative overhead.
> Domain0, as the main provider of device access, its function is relatively
> fixed and administrative overhead should be avoided to reduce the burden on
> VMM. 

So.. remove the administration from Dom0. But why? What are the 
disadvantages of doing this in Dom0?

> 4) scheduling Delay 
> Domain0 and other virtual machines take part in VMM scheduling, due to
> scheduling rotation characteristics, Domain0 can not guarantee timely
> delivery of services, which results a number of related issues. First, after
> VMM receive IO request from virtual machine, Domain0 could not be
> immediately notice, only asynchronous notice way which similar to soft
> interrupt can be used, and Domian0 will test and process it when running.
> Second, device model of Domain0 is provided by Qemu, which is running as a
> process of guest OS. When Domain0 is not running, Qemu can not handle IO
> requests from virtual machine, resulting in delay of processing IO requests.

If you are using legacy hardware in QEMU - sure. But nowadays every Linux
distro has drivers to use the PV drivers which omit QEMU. Also they are
available under Windows (even WHQL certified ones).
Furtheremore the stub-domains eliminate this.

Anyhow, I stopped reading after this..