Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

[Ingo Molnar <mingo@elte.hu>]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> > While that's basically what we did in Xen, it would make more sense 
> > to build it into genapic which would give us one common abstraction 
> > to base from.  We should avoid adding pv_ops when existing 
> > infrastructure exists.
> 
> I was looking at cutting in at a much higher level.  The interface in 
> <linux/smp.h> is a good match for Xen, so I was going to investigate 
> making pv_ops at that level and see how it falls out.

yes, yes, yes. Finally someone with a clue about APIs ;-)

Basically, we want to think about the hypercall API more like a system 
call API, not like a hardware API! There will probably still be lowlevel 
details like ptes for a long time - but even those are not quite 
necessary.

And the reason is really fundamental: those system-call alike APIs are 
going to be the /most stable ones/ over time! 'Send stuff from A to B' 
or 'notify X about event Y' is /ALOT/ more stable across hardware 
variations than 'IDTs, vectors, apics or ptes'. And that is so precisely 
because these are fundamental actions that physical matter can do, and 
those do not get changed when new silicon comes out. In that sense Xen's 
hypervisor API is saner than VMI.

the most highlevel API is what UML uses today (and it clearly overdoes 
abstraction), still i was able to get basic UML performance close to 
native performance, via extending a few Linux system calls to enable the 
management of multiple sets of pagetables (each represented by a 
separate fd) via a single hypervisor-level process, and feeding back raw 
pagefault events to the hypervisor. (that was UML's SKAS concept 
combined with sys_remap_file_pages_prot() and sys_vcpu())

Now the practical problem with UML is that nobody has tried to make an 
UML native+guest 'shared kernel image', and hence it's unusable for 
distros. But there is no conceptual problem with UML's virtualization 
model.

	Ingo