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

Ingo Molnar
2007-03-08T19:56:00Z

* 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