Ingo Molnar wrote:
> ok, sure, how about the one i mentioned: 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?
You wouldn't. Why would you? It might be a useful interface - and its
the perfect kind of high-level interface for pv_ops. It might be worth
adapting a hypervisor to suit it, but you still need to support the
i386's pagetables. So, you present the pv_ops interface with your
vma-based mappings, and it runs it through the vma->pagetable
translation layer to feed into either the i386 pagetables directly, or
to a hypervisor's page-based interface.
The important part is that there's more to the story than just pv_ops.
If you wanted to make such a change, then you'd need to refactor the
i386 support code to add a vma->paging helper layer. That layer would
be available for any pv_ops interface to use if it wishes.
(Remember, in the pv_ops model, bare hardware is a "hypervisor" too.)
Next problem?
J
-
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/
