> The VMM emulates some interesting hardware: a device that can read the latest tweet from Command Line Magic’s Twitter handle, a device that can get the weather from certain cities, another device that can read fetch the latest air quality measurements from certain cities and finally a console device that lets the virtual machine read the keyboard and output text to the terminal.
This is one of the under-appreciated fun things about virtualization: the ability to pretty much make up 'hardware' devices, and completely rethink the way that the hardware should work. No need to be a PC when you can be anything you want. Obviously it's possible to do all the same stuff with hardware, or even kernel drivers, but the KVM interface makes it really easy and fun.
Does anyone know why the API was designed this way? Sending a bunch of ioctls to modify the KVM state seems no better than just having normal function calls for it…
Seeing as how they're mmap()ing the fds, it makes some sense to leverage the other file_operations.
- ioctls on char/blkdevs for either physical or logical devices (which also allow for a 'handle' paradigm of operation, and for event polling via epoll/select)
- sysfs and procfs entries for system and process tunables and data
- debugfs for day to day debugging (which is explicitely unstable and not enabled in most production kernels)
- prctl, fcntl, ...
In addition, all of the above is 'automatically' ported across architectures. Some Linux architecture ports have their own syscall tables (with own numbering) and need to be explicitly modified any time a syscall is added.