Re: ABI coupling to hypervisors via CONFIG_PARAVIRT

[Ingo Molnar <mingo@elte.hu>]

* Chris Wright <chrisw@sous-sol.org> wrote:

> * Ingo Molnar (mingo@elte.hu) 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