Re: ABI coupling to hypervisors via CONFIG_PARAVIRT

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > but ... maybe because VMI is so lowlevel and covers /all/ of x86 
> > today, it will always be able to emulate whatever different concept 
> > we can come up with? Do we really know this absolutely sure?
> 
> "For sure"? Absolutely not. But since any new interfaces we come up 
> with for doing timers etc had better work perfectly fine on an old 
> hardware platform too, we can't exactly require any interfaces that do 
> things that a bog-standard old dual-PPro didn't do 10 years ago, can 
> we?

i'm not really thinking in terms of extending the native kernel - 
whatever we do on the native kernel we'll indeed have to be able to do 
on 'real' hardware too - including really old boxes.

i'm thinking more in terms of having some new and more intelligent 
virtualization-only abstractions.

For example i think people are way too obsessed with building virtual 
'machines' that look like PCs, while i've got some truly pie-in-the-sky 
ideas floating to simplify virtual machines, like the one i just 
outlined to Chris:

|| long-term i'd like to have a paravirt model where the guest does not 
|| store /any/ page tables - all paging is managed by the hypervisor. 
|| The guest has a vma tree, but otherwise it does not process 
|| pagefaults, has no concept of a pte (if in paravirt mode), has no 
|| concept of kernel page tables either: there are hypercalls to 
|| allocate/free guest-kernel memory, etc. This needs some (serious) MM 
|| surgery but it's doable and it's interesting as well. How would you 
|| map this to the VMI backend?

Clearly the ugliest and most complex part of hypervisors is MMU support. 
So the above model would avoid all the shadow page table complexities 
and other MMU nasties, and keep that stuff in the hypervisor. [ in 
exchange for a whole set of other complexities and problems ;-) ] This 
would be even more highlevel than UML (UML emulates pagetables in 
user-space), in that regard.

even in such a drastic model we could share like 90% of the x86 binary 
code with the rest of the kernel (all the filesystem support, networking 
stack, etc. would still be reusable by the guest kernel), so a paravirt 
approach, where native and guest is the same image (as opposed to the 
UML model, where they are separate) still makes sense and is preferred 
by distributions.

Mapping this into VMI calls looks ... near impossible to me. VMI really 
assumes that there is no hypervisor state for kernel objects - while the 
above model _shares_ a very substantial kernel object with the 
hypervisor - and in fact 100% delegates its handling to the hypervisor 
altogether. Hm?

	Ingo