Multiple virtual machines running on the same host are sharing hardware resources, memory in particular. This opens up opportunities for sharing and communication between them that are impossible for physical machines without fairly exotic hardware.
One possibility is for separate UMLs to share a filesystem. This would be implemented by configuring a UML so that it consists of the filesystem code, the block layer, the UML block driver, and whatever supporting code that these systems require. It would not contain a number of things which are normally considered essential for a kernel, such as process support and virtual memory.
It would have its own memory pool, which would be mapped, together with its code, into the address spaces of a number of UMLs. This would be seen by the virtual machines as something very similar to a kernel module that implements a filesystem. They would mount it normally, and accesses to that filesystem would be handled by this shared code.
All of the virtual machines would perceive this filesystem to be local, even though it's really not owned by any of them. This would be a high-performance alternative to filesystems such as NFS when a shared read-write filesystem is required.
The code in the shared subsystem would effectively be SMP (and it would need to be compiled as such) since multiple virtual machines could be executing the code and accessing its data simultaneously. Since the virtual machines could be UP, this arrangement would create a set of hybrid UP-SMP virtual machines.
Configuring the kernel into this minimal, very specialized, role would require changes in the generic kernel. Capabilities that are normally mandatory would become optional. The kernel startup would need to be changed so that it doesn't attempt to boot a system by running init. Instead, the startup code would be executed by one of the virtual machines using it, and it would return after doing the necessary setup of its own data.
Filesystems aren't the only subsystems that could be shared in this way. For some applications, a shared block device, with either no filesystem or a distributed filesystem, would be useful. Another possibility is the network subsystem. Sharing it would effectively create a shared network device which the virtual machines could use to communicate with the outside world.
These are obviously useful for virtual machines running on the same host. They offer performance advantages and more efficient use of the host resources. These advantages would also apply to physical machines, if this arrangement can be realized in actual hardware. Devirtualizing the shared filesystem would result in a multiported disk with its own memory that is mapped into the memory of each machine that has access to it. This memory contains the code and data described above, and the native kernels would treat it as a module in exactly the same way that UML would.
This physical disk would offer the same advantages to the physical machines as the shared virtual filesystem offers to UMLs. If this happens, it would create a new area of application for UML - prototyping new devices virtually in order to see what uses they may have, and if they turn out to be useful enough, implementing them physically in hardware.