* Linus Torvalds <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
