On 02/07/2012 08:12 PM, Rusty Russell wrote:
I would really love to have this, but the problem is that we'd need a
general purpose bytecode VM with binding to some kernel APIs. The
bytecode VM, if made general enough to host more complicated devices,
would likely be much larger than the actual code we have in the kernel now.
We have the ability to upload bytecode into the kernel already. It's in
a great bytecode interpreted by the CPU itself.
Unfortunately it's inflexible (has to come with the kernel) and open to
security vulnerabilities.
If every user were emulating different machines, LPF this would make
sense. Are they?
They aren't.
Or should we write those helpers once, in C, and
provide that for them.
There are many of them: PIT/PIC/IOAPIC/MSIX tables/HPET/kvmclock/Hyper-V
stuff/vhost-net/DMA remapping/IO remapping (just for x86), and some of
them are quite complicated. However implementing them in bytecode
amounts to exposing a stable kernel ABI, since they use such a vast
range of kernel services.