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..
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home
