The arrow of time

A problem that soon arises is - what about performance? The currently obvious solution is to add paravirtualization features like VMWare VMI and Xen dom0 to both the guest kernel and (with somewhat  less intrusiveness) to the host kernel. Paravirtualized virtual machines don't pretend they're accessing actual hardware but call into the VM host environment for common functions. This also simplifies the VM host as it doesn't have to emulate hardware (like PCI access) but can use a more efficient protocol for the purpose.

What about all the efforts invested in modern kernel infrastructure and algorithms at the guest side? Does it mean that it's completely irrelevant what kind of CPU scheduler is implemented in the guest since the code is eventually rescheduled in the VM host OS (probably yes)? Does it mean  file system journalling is useless on the guest side if it's properly implemented (full data journalling) on the host (probably yes)? Does it mean memory is wasted on disk caching in the guest VM (maybe yes, maybe no, since the local kernel knows how to track which local file blocks are accessed and why)? How much performance could be recovered by simply using the dumbest algorithms in the guest kernel?

The question is - where does this stop? Do we have a function that reads a block from an (emulated) drive and returns it? A function that passes packets in memory from the host to the guest? Replace the interrupt table and the concept of interrupts with a table of fuction pointers for callbacks (ala method dispatch in OOP)? At the extreme, does a wholly paravirtualized kernel reduce to a microkernel passing messages between the userland and the hypervisor?

At the end, what really matters beyond a certain point is the userland - how consistent it is (a plus for FreeBSD) and how many applications are available (plus for Linux and Windows).