xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/23/2006 06:45:54 PM:
> Keir Fraser wrote:
> > We could extend the concept of the interface shim we already have -- a
> > set of OS-specific high performance shims, plus a fallback OS-agnostic
> > shim.
>
> Currently the lack of a shim is the key difference between the VMI and
> Xen approaches. Forgive me for summarizing, but I'm not sure it's been
> made clear. The VMI is the interface between the OS and a shim layer--it
> is not a hypervisor interface. The kernel makes VMI calls to the shim
> and the shim makes hypercalls, if needed, to the hypervisor.
>
> VMI VMI native Xen/Xen native
>
>
> OS OS OS
> -------------- VMI -------------- VMI
> Shim (ROM)
> -------------- HV API -------------- HV API
> Hypervisor Native HW Hypervisor
>
Although this is about VMI, one should not loose sight of this one here
with an unmodified OS on virtualizeable hardware:
Native
OS
----------------
Hypervisor
I think building this could actually be the driving force that can dictate
*a lot* of what happens in 'Hypervisor' and what by that implementation
alone is offered to the OS by 'Hypervisor' in terms of components. It
would necessarily have to end up being a 'PC emulator'. Parts of that
Hypervisor architecture can then also be made available to interface with
the ROM shown above - not that this has not been done for Xen, but the
Qemu models seem to be very far away in domain 0. Xen in contrast has been
optimized for speed. I wonder whether the two goals of performanc and PC
emulaton are in fact mutually exclusive.
Stefan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osdl.org/pipermail/virtualization/attachments/20060323/99a3d79a/attachment.htm
