* Chris Wright <[EMAIL PROTECTED]> wrote:
> * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > i am worried whether /any/ future change to the upstream kernel's design
> > can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
> > mean truly any. And whether that can be done is not a function of the
> > flexibility of paravirt_ops, it's a function of the flexibility of the
> > VMI ABI.
>
> i'm not really one to argue on behalf of VMI, but i don't think it's
> as dire make it out. [...]
hey, that's what i thought when i helped do the vDSO, until i got
slapped with cold reality called "CONFIG_COMPAT_VDSO". I'm a bit more
careful about ABIs since then =B-)
> [...] the VMI is client code of pv_ops, and as the kernel changes that
> client code will simply have to adapt. of course there are
> theoretical limitations, but let's keep it grounded to practical
> reality. the whole premise is evolution. so throw out specific
> issues, and let's adapt rather than fall deep into theoretical
> rhetoric.
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?
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/
