RE: [Xen-devel] Re: [Xen-changelog] Indirect hypercalls through ahypercall transfer page.

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

 > On Wed, 2006-01-25 at 13:58 +0000, Xen patchbot -unstable wrote:
> > # HG changeset patch
> > # User kaf24@xxxxxxxxxxxxxxxxxxxx
> > # Node ID 71914b64b5770285cf095c1906e346b814f4878b
> > # Parent  246b6444c6432193ea98c9f01de58e6740bde09c
> > Indirect hypercalls through a hypercall transfer page.
> 
> Sorry, I may have missed some conversation about this...
> 
> What is this patch about? I mean I can see how it works, but 
> what is the motivation for it?

The primary reason for this patch is that it will enable us to run a
xenified kernel on bare metal: a 'micro xen' would be loaded by the boot
loader alongside a xenified kernel image, enabling the kernel to
effectively run on the baremetal at full native performance (though
obviously you could only run one kernel on a machine at a time).

The nice thing about this approach is that a vendor could certify their
app running on an OS over Xen, and have good confidence that it would
then run stably on the OS running over 'microxen', as microxen just
doesn't implement the type checking enforcement and multiplexing that
real xen does. Doing things this way around is certinly the best way of
getting assurance without having to certify apps twice. It requires a
bit of a leap-of-faith that virtualization is going to be so common
place on servers that the paravirtualized kernel should be the one used
for certification, but it's a sound technical argument. Any scheme that
doesn't certify with the kernel actually running over the hypervisor
(whatever the hypervisor) is fairly delusional. 

Implementing microxen is pretty straight forward. One could implement a
prototype just by deleteing huge swathes of code from xen, but it
probably makes sense to go for something really minimalist. The OS
kernel would run in ring 0 (alongside microxen) and would use the xen
transfer page hypercall mechanism to simply jump into microxen to
implement the xen api using the normal privileged instructions (mov cr3
etc). Xen guests only use a handful of hypercalls, and most of the code
for high frequency ones can just be in-lined in the transfer page.

Another nice feature of this approach is that if the CPU vendors add
certain new features [e.g. a tagged TLB (Address Space Numbers),
multicast IPIs etc] the same xenified guest kernel would be able to
imediately take advantage of them. Further, as full virtualization
hardware assist (VT/Pacifica) improves in performance over the next few
years, it may make sense to start running xen-ified kernels in hvm
partitions using the microxen shim. We'd be able to tune what gets done
in hardware vs software by adjusting the shim, which is dropped in by
the domain builder.


Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel