Re: [RFC, PATCH 4/24] i386 Vmi inline implementation

[Zachary Amsden <zach@vmware.com>]

Pavel Machek wrote:
> We already do runtime patching for SMP vs. UP, could you use same
> infrastructure? I do not want VMI-specific grub.

I think we could almost use the same infrastructure - or extend it to 
work.  The problem is how to determine register liveness for calls into 
the VMI layer which take > 3 arguments.  If you squeeze all the 
arguments into fixed registers, you can unnecessarily constrain the 
native code - and rapidly run out of registers for the compiler to use, 
generating impossible constraints in some cases.

To work around these issues, we do not constrain the arguments beyond 
the first three registers.  But this means that the hypervisor needs a 
way to locate the additional arguments.  That information gets encoded 
implicitly by the auto-generated translation into a VMI call, which 
pushes the arguments onto the stack (thus revealing the registers, and 
allowing constant immediate optimization).

Now, if you can generate all of the code to do the callout to the VMI, 
you could use it directly in an alternative instruction sequence, just 
as the existing infrastructure.  But I'm not sure you can do it in one 
compiler pass.  We are already pushing the limits of the preprocessor, 
compiler and assembler here.  Having another preprocessing pass may make 
it possible, but it does make the build more complicated.

I'm not sure it is really what we want though.  The alternative 
instruction interfaces is based on global feature detection that is done 
and applied by the _kernel_.  In the end, we want the hypervisor to be 
able to toggle each VMI call site as a separate feature, and replace it 
with hypervisor specific code.  In this way, a VT based hypervisor could 
simply not patch those class of VMI calls that are already emulated by 
hardware, and also inline direct hypercalls for those classes that are 
not.  The VMI layer is supposed to be very much an inline linker for 
feature detection done by the _hypervisor_.

Zach